Re: [drlvm] Helper inlining in JIT
MIkhail, I have some questions, or just arguments :-) First, though it is nice to talk of an open helper inlining framework to call VM/GC helpers, isn't the set of helpers used in JVM's more or less well known and standardized? In other words, is a framework absolutely necessary, can't the jit just generate code inline for the known fastpath of the helper algorithm? For example if we replaced the DRLVM gc with gc_new , how many new helpers do you think we would introduce? Also, please see below for some inline comments... On 8/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: >Even this simple helper reveals a lot of features to support: >1) Access to TLS is required. It could be fs:[14h] on Windows or helper call >on Linux (depends on kernel (?) ). Even if we have an access to TLS we need >to know the offsets of our slots: 'current' and 'ceiling' in example. >So we need to have a way to pass these values to JIT. May be a 'private >static final' variables in the helper's class with special runtime >annotations could be used to pass the values to JIT? So basically, every new VM would need to implement the helper in an almost identical way or at least using identical final variables...I wonder how much flexibility that leaves .. 2) Calls support is needed. Both for "slow" helper version and to access >TLS. >This means also that calling convention support is needed. Runtime level >annotations for helper calls could be used here. E.g. create a magic method >'slow_alloc' and teach JIT to call real helper instead of it. Get the >calling convention info from annotation (?) Is it not possible for the fastpath helper to just return a failure so that the jit generated conventional helper callpath can kick in. In other words, does the slow helper have to be called from the fast helper? 3) Do we really want to expose native regs to Java: EAX, ECX... I vote do >not to use them when writing helpers in Java and to allow to JIT to optimize >unboxed operations (allocate registers by itself) This again goes back to my original question...if the JIT knew the standard fastpath, it could generate code optimally for it anyway with the best use of registers? These are just arguments before we set off developing a framework. I would like to know if helpers vary a lot across VM implementations, seems to me they need to do the same old things. Even if a framework is needed, it seems that we will land up inventing a language with unboxed primitives, virtual register access and special calling conventions for it to work optimally. And then we want every VM to use this language to code fastpath helpers and also to code the slower helpers in the conventional way. Maybe we should ask VM developers to vote on how open this is Thanks, Rana
Re: Re: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Cool, thanks. On 11/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: Done in 430723 Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Geir, can you please add that patch to the JIRA entry? It's not a patch, but a bug workaround or better to say - dirty hack. I'd better try to solve the core problem and provide the proper patch in few days. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] platform support
Any _primary_ platform that will be supported by Harmony will probably need to be put thru a pretty full test protocol on that platform independent of whether it uses the same binary or a different binary. I doubt that the Harmony community will want to target all possible OS combinations initially. I think that we should have a serious discussion on this list about the OS combinations for which we have "volunteers on board" for "Harmony 1.0". I don't believe that Harmony should achieve ubiquity by using least common denominator interfaces. For x86 32bit-mode systems, I do think we'll probably need to limit ourselves to one or two binaries. See http://java.sun.com/j2se/1.5.0/system-configurations.html and http://edocs.bea.com/jrockit/jrdocs/suppPlat/supp_50.html a list of what combinations Sun and BEA support today with their Java5 solutions. I am unconvinced that a combined binary will make testing any easier. I believe that the makefile (oops, I mean ant) structure will be easier with a combined binary but the startup code and some platform specific optimization code will be more complex as it will need a pretty sophisticated platform determination and a somewhat manual library loading process. At the same time, I believe a combined binary that includes multipath checks will simplify distribution. I also believe that something similar will be necessary for Linuxes though perhaps not as sophisticated. Lets say that we decide to go for "complete", "optimal", windows support. We would have special case code that chooses appropriate library interfaces at startup for somewhere between 7 and 18 different versions of x86 windows, not accounting for service packs: * x86 Vista home, pro, tablet * x86 Vista/Longhorn server, webserver * x86 Vista/longhorn enterprise * x86 XP home, pro, tablet, media * x86 XP/2003 server, webserver, Enterprise, Datacenter * x86 W2K * x86 W2K Server, W2K Advanced Server, Datacenter This of course doesn't account for the either EM64T or Itanium family processor based systems. Maybe someone needs to take each OS platform and list what special interfaces are useful for each one. I'm particularly partial to some of the interfaces available only on the server versions such as the large page APIs: http://windowssdk.msdn.microsoft.com/en-us/library/ms694004.aspx. http://windowssdk.msdn.microsoft.com/en-us/library/ms724833.aspx talks about how to distinguish the different versions and service packs from each other. This is probably pretty useful information to report back to JIRA in the case of a VM crash if we have a single binary release model. Of course if one wants to be able to run on windowsMe or Windows98, one can't rely on these interfaces... But then since these aren't actively supported by Microsoft anymore, its unclear how relevant those platforms are. Thanks, Chris Elford Intel Middleware Products Division -Original Message- From: Rana Dasgupta [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 10:51 AM To: harmony-dev@incubator.apache.org Subject: Re: [general] platform support Hi Mikhail, As far as I know, SetUnhandledExceptionFilter was introduced as a backdoor method in in Win2K SP4 to get around the problem that the SEH handlers are limited to the frame and not process wide. It does handle problems like NPE and AV, but as you point out, it works by hijacking the first and last chance debugger handlers. So, unlike VEH which are fully functional when debugging, these SetUnhandled...filters are not visible when debugging. I also believe that they execute in the context of the current thread, which means that they are not so good to handle stack corruption, SOE etc. which we are currently using VEH. Since one does not expect them to be used on the newer Windows boxes, the .Net framework overwrites them ...which means that any process that loads a Microsoft dll that has any Microsoft managed code in it ( and many do ), is at a risk that the SetUnhandled.. may or may not work. I think that SetUnhandled..was a great(probably only ) solution on the Win2K boxes, but VEH was put in place to solve some of its limitations. The bottom line is that one needs to experiment with this on several Windows boxes before we know how good or bad it is. I myself don't have a lot of experience with it. Thanks, Rana On 8/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > > >**Using "SetUnhandledExceptionFilter" API call we can handle hardware NPE > >for Win2k too. > >The only problem is debbuging of applications with exception filter > >installed. AFAIK debugger will catch all of these events. > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
can you please add that patch to the JIRA entry?
Anton Luht wrote:
> Hello,
>
> Yes, the problem with verifier is partly solved but problems in verifier
> remain.
>
> method vf_resolve_class( name, true, ctex ) from ver_utils.cpp
> sometimes returns null when vf_resolve_class( name, false, ctex )
> returns non-null for same class name. This method is for looking up
> classes, if I understand correctly, 'true' means load class if not
> loaded and 'false' - just take from cache anything that is there,
> don't try to load. The situation when class is in cache and 'deep'
> load can't find it shouldn't happen.
>
> Temp workaround for this bug before deep investigation can be:
>
> Index: ver_utils.cpp
> ===
> --- ver_utils.cpp (revision 430763)
> +++ ver_utils.cpp (working copy)
> @@ -1391,6 +1391,9 @@
>
> // get stack reference class
> class_handler source = vf_resolve_class( constraint->source, true,
> ctex );
> +if(source == NULL) {
> + source = vf_resolve_class( constraint->source, false, ctex );
> +}
> if( !source ) {
> VERIFY_DEBUG( "verifying class " << class_get_name( ctex->m_class )
> << " (method " << method_get_name( constraint->method )
>
>
> after that the activemq start fails with message:
>
> ERROR: java.lang.RuntimeException: Failed to execute start task. Reason:
> java.la
> ng.ArrayStoreException
>
> To be continued.
>
> On 8/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> I think I've fixed this a few days ago and attached the patch to JIRA.
>> See
>> my emails in this thread. Does it fix the problem with verifier for you?
>>
>> The problem with verifier is only the first one with activemq. After I
>> fixed
>> the exception problem the app still didn't start up.
>>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Winstone servlet engine fixed to run on Harmony
ASAP :) Martin Cordova wrote: > Geir, is there a planned release date for the Image/Graphics2D stuff? > I thought that the Intel contribution covered this very well. > > Regards, > Martin > > > On 8/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: >> >> >> Martin Cordova wrote: >> > The author of Winstone detected the problem that generated an >> > exception when running on Harmony and fixed it the same day. >> > >> > My first impressions: Harmony JRE snapshot is fast. All database I/O >> > code from my webapp did run fine, as well as all network I/O. I could >> > not test PDF (IText) and Charts (JFreeChart) creation because certain >> > Image classes are not implemented yet. I will as soon as they become >> > available. >> >> That's really great to hear! >> >> > >> > My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support >> > for server sockets. >> > >> > I will keep you informed. >> > >> >> That's for doing this :) >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][suncompat] created
Tim Ellison wrote: > Oleg Khaschansky wrote: >> Another solution is to create stubs which will throw exceptions with >> detailed message. Then users will get neccessary information but >> functionality won't be enabled by default. > > I'd like to inflict just a little bit of pain (but maybe that is my > warped personality ;-) ). If people have gone to the trouble of getting > harmony to try it then expecting them to uncomment a line in the > properties file as penance not unreasonable IMHO. Why should there be penance for using Harmony? We should be falling all over ourselves at this point trying to get people working with it. > > So you may be onto something ... perhaps we also have an uncompat.jar > included by default, that implements those types to always print out an > impolite message on the console and quit: > > *** your app is rubbish, go to jre/lib/boot/bootclasspath.properties > *** and uncomment this line... > I think that we can achieve both goals through inclusion to make things "just work" as much as we can, and also very good documentation, FAQs, support etc to make people aware and how to fix... geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] *.boot.class.path propoerty setting (Was Re: [classlib] [ldap] support for multiple VMs?)
2006/8/11, Geir Magnusson Jr <[EMAIL PROTECTED]>: I was going to talk about the exact thing when I had a chance, so glad you beat me to it. I'm just changing the subject line so it's clearer. Inline. Alexey Varlamov wrote: > A bit offttopic for this thread, but I'd like to discuss the following > points for the boot.class.path property: > 1) Whose responsibility is to set this property (launcher, VM or > classlib)? Now we have at least 3 implementations: > a) readClassPathFromPropertiesFile() in > classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c > b) readClassPathFromPropertiesFile() in > classlib\modules\luni\src\main\native\luni\shared\luniglob.c > c) load_full_api_files_path_names_list() in > drlvm\vm\vmcore\src\init\properties.cpp > BTW, the first 2 seems to be just copy-paste copies. I believe there > should be just single agent doing this task, most natural candidate is > shared VM launcher. I also thought the launcher was the right place, but not so sure, as you wouldn't want to handcuff the VM implementations as to what kinds of features they can add here. Maybe VM launcher sets it originally, but the VM is free to override? I suggest that launcher pass the bootclasspath string among other VMOptions. It can even (re)use "-Xbootclasspath:" argument - that is, such argument would be specified either by user or by the launcher itself. > > 2) Current parsers of the bootclasspath.properties are fragile in > relation to format of this file: the file must end with line delimiter > and must have strict platform line delimiters, otherwise jvm just > hangs. Should I file new JIRA or this is intentional? Please file a JIRA. Hanging can never be intentional. :) geir > > > 2006/8/11, Tim Ellison <[EMAIL PROTECTED]>: >> Daniel Gandara wrote: >> > Hi all, >> > >> > We are working on the javax.naming.ldap and we are facing the >> > following issue when thinking about supporting multiple VMs. >> > Following the SPEC there is a method createExtendedResponse in the >> > StartTlsRequest class which states that the returning object must be >> > an instance of a concrete subclass of StartTlsResponse and must have >> > a public zero-argument constructor. The concrete subclass is >> > determined by reading the configuration file located in >> > META-INF/services/javax.naming.ldap.StartTlsResponse (see >> > >> http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) >> >> > >> > The search for this configuration file is done by looking in the >> > classpath, java.home and user.dir; also the Xbootclasspath should be >> > inspected, and that seems to be a problematic situation, since there >> > is not a standard property to look for its value. Different VM >> > implementations have different property names for the boot class path >> > value. In the old Harmony VM implementation was >> > com.ibm.oti.system.class.path; in the new one is >> > org.apache.harmony.boot.class. The property name in the Sun's VM is >> > sun.boot.class.path. We are wondering which property name to use in >> > the code. At first sight the Harmony new VM implementation property >> > seems to be the better option, but maybe looking for the other >> > properties will be interesting for compatibility purposes. >> > >> > We would be very interested in opinions. >> >> I'd ignore the com.ibm property and look through the path defined by >> org.apache.harmony.boot.class.path >> >> I don't know what property is set by the DRLVM / JCHEVM / etc., but it >> would be good if they set the same property (maybe in addition to their >> current property). >> >> If you want the code to run on the Sun implementation too then you >> should *also* search the sun.boot.class.path, and of course be tolerant >> of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal >> for you? It's not something that we would require for including the >> LDAP code in Harmony. >> >> Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTE
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Hello,
Yes, the problem with verifier is partly solved but problems in verifier remain.
method vf_resolve_class( name, true, ctex ) from ver_utils.cpp
sometimes returns null when vf_resolve_class( name, false, ctex )
returns non-null for same class name. This method is for looking up
classes, if I understand correctly, 'true' means load class if not
loaded and 'false' - just take from cache anything that is there,
don't try to load. The situation when class is in cache and 'deep'
load can't find it shouldn't happen.
Temp workaround for this bug before deep investigation can be:
Index: ver_utils.cpp
===
--- ver_utils.cpp (revision 430763)
+++ ver_utils.cpp (working copy)
@@ -1391,6 +1391,9 @@
// get stack reference class
class_handler source = vf_resolve_class( constraint->source, true, ctex );
+if(source == NULL) {
+ source = vf_resolve_class( constraint->source, false, ctex );
+}
if( !source ) {
VERIFY_DEBUG( "verifying class " << class_get_name( ctex->m_class )
<< " (method " << method_get_name( constraint->method )
after that the activemq start fails with message:
ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: java.la
ng.ArrayStoreException
To be continued.
On 8/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
I think I've fixed this a few days ago and attached the patch to JIRA. See
my emails in this thread. Does it fix the problem with verifier for you?
The problem with verifier is only the first one with activemq. After I fixed
the exception problem the app still didn't start up.
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [ldap] support for multiple VMs?
2006/8/11, Gregory Shimansky <[EMAIL PROTECTED]>:
2006/8/11, Tim Ellison <[EMAIL PROTECTED]>:
>
> Daniel Gandara wrote:
> > Hi all,
> >
> > We are working on the javax.naming.ldap and we are facing the
> > following issue when thinking about supporting multiple VMs.
> > Following the SPEC there is a method createExtendedResponse in the
> > StartTlsRequest class which states that the returning object must be
> > an instance of a concrete subclass of StartTlsResponse and must have
> > a public zero-argument constructor. The concrete subclass is
> > determined by reading the configuration file located in
> > META-INF/services/javax.naming.ldap.StartTlsResponse (see
> >
> http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html
> )
> >
> > The search for this configuration file is done by looking in the
> > classpath, java.home and user.dir; also the Xbootclasspath should be
> > inspected, and that seems to be a problematic situation, since there
> > is not a standard property to look for its value. Different VM
> > implementations have different property names for the boot class path
> > value. In the old Harmony VM implementation was
> > com.ibm.oti.system.class.path; in the new one is
> > org.apache.harmony.boot.class. The property name in the Sun's VM is
> > sun.boot.class.path. We are wondering which property name to use in
> > the code. At first sight the Harmony new VM implementation property
> > seems to be the better option, but maybe looking for the other
> > properties will be interesting for compatibility purposes.
> >
> > We would be very interested in opinions.
>
> I'd ignore the com.ibm property and look through the path defined by
> org.apache.harmony.boot.class.path
>
> I don't know what property is set by the DRLVM / JCHEVM / etc., but it
> would be good if they set the same property (maybe in addition to their
> current property).
DRLVM sets two propeties with the same value. The one which is used by VM is
vm.boot.class.path and another added for compatibility with some
applications is sun.boot.class.path. It is not used inside of VM. I compared
values with org.apache.harmony.boot.class.path with is set in classlib luni
and foind that the only difference is with kernel.jar absent in it and
present in DRLVM properties. It is logical because they both read the same
bootclasspath.properties file but VM also adds kernel.jar before everything.
I wonder if DRLVM starts to use the same
org.apache.harmony.boot.class.pathproperty wouldn't it be overwritten
with luni initialization with value
wihout kernel.jar?
Besides, the luni init only recognizes "-Xbootclasspath:" runtime
parameter, but not "append"/"prepend" variants
("-Xbootclasspath[/a|/p]:"). Yet another argument to unify and share
such code. Is there any reason to do this in classlib?
--
Alexey
If you want the code to run on the Sun implementation too then you
> should *also* search the sun.boot.class.path, and of course be tolerant
> of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal
> for you? It's not something that we would require for including the
> LDAP code in Harmony.
>
> Regards,
> Tim
>
>
--
Gregory Shimansky, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][suncompat] created
On Fri, Aug 11, 2006 at 03:23:51PM +0100, Tim Ellison wrote: > Oleg Khaschansky wrote: > > Another solution is to create stubs which will throw exceptions with > > detailed message. Then users will get neccessary information but > > functionality won't be enabled by default. > > I'd like to inflict just a little bit of pain (but maybe that is my > warped personality ;-) ). If people have gone to the trouble of getting > harmony to try it then expecting them to uncomment a line in the > properties file as penance not unreasonable IMHO. > > So you may be onto something ... perhaps we also have an uncompat.jar > included by default, that implements those types to always print out an > impolite message on the console and quit: > > *** your app is rubbish, go to jre/lib/boot/bootclasspath.properties > *** and uncomment this line... > That's letting them off the hook too easily ... look up the class using docjar & maven, find the associated bugtracker, and file a bug automatically. that'll teach them. :) sadistically yours, dalibor topic > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Winstone servlet engine fixed to run on Harmony
Geir, is there a planned release date for the Image/Graphics2D stuff? I thought that the Intel contribution covered this very well. Regards, Martin On 8/11/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Martin Cordova wrote: > The author of Winstone detected the problem that generated an > exception when running on Harmony and fixed it the same day. > > My first impressions: Harmony JRE snapshot is fast. All database I/O > code from my webapp did run fine, as well as all network I/O. I could > not test PDF (IText) and Charts (JFreeChart) creation because certain > Image classes are not implemented yet. I will as soon as they become > available. That's really great to hear! > > My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support > for server sockets. > > I will keep you informed. > That's for doing this :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [ldap] support for multiple VMs?
2006/8/11, Tim Ellison <[EMAIL PROTECTED]>: Daniel Gandara wrote: > Hi all, > > We are working on the javax.naming.ldap and we are facing the > following issue when thinking about supporting multiple VMs. > Following the SPEC there is a method createExtendedResponse in the > StartTlsRequest class which states that the returning object must be > an instance of a concrete subclass of StartTlsResponse and must have > a public zero-argument constructor. The concrete subclass is > determined by reading the configuration file located in > META-INF/services/javax.naming.ldap.StartTlsResponse (see > http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html ) > > The search for this configuration file is done by looking in the > classpath, java.home and user.dir; also the Xbootclasspath should be > inspected, and that seems to be a problematic situation, since there > is not a standard property to look for its value. Different VM > implementations have different property names for the boot class path > value. In the old Harmony VM implementation was > com.ibm.oti.system.class.path; in the new one is > org.apache.harmony.boot.class. The property name in the Sun's VM is > sun.boot.class.path. We are wondering which property name to use in > the code. At first sight the Harmony new VM implementation property > seems to be the better option, but maybe looking for the other > properties will be interesting for compatibility purposes. > > We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). DRLVM sets two propeties with the same value. The one which is used by VM is vm.boot.class.path and another added for compatibility with some applications is sun.boot.class.path. It is not used inside of VM. I compared values with org.apache.harmony.boot.class.path with is set in classlib luni and foind that the only difference is with kernel.jar absent in it and present in DRLVM properties. It is logical because they both read the same bootclasspath.properties file but VM also adds kernel.jar before everything. I wonder if DRLVM starts to use the same org.apache.harmony.boot.class.pathproperty wouldn't it be overwritten with luni initialization with value wihout kernel.jar? If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? It's not something that we would require for including the LDAP code in Harmony. Regards, Tim -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib][suncompat] created
Oleg Khaschansky wrote: > Another solution is to create stubs which will throw exceptions with > detailed message. Then users will get neccessary information but > functionality won't be enabled by default. I'd like to inflict just a little bit of pain (but maybe that is my warped personality ;-) ). If people have gone to the trouble of getting harmony to try it then expecting them to uncomment a line in the properties file as penance not unreasonable IMHO. So you may be onto something ... perhaps we also have an uncompat.jar included by default, that implements those types to always print out an impolite message on the console and quit: *** your app is rubbish, go to jre/lib/boot/bootclasspath.properties *** and uncomment this line... Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Helper inlining in JIT
On 8/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: On 8/9/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: > a) Fast access to TLS. Yes! Good idea. What you want is a "mov eax, fs[14]" intrinsic for winxp and the equivalent for Linux. It may be a stretch for vmmagic purists to add segment register address arithmetic to vmmagic. Worst case, Harmony could add the segment register facility to Harmony svn. Exactly, To see why support of calls and calling conventions is also important I propose to try to write a real helper using unboxed types. This way we can prove that the solution does really work, check if the solution is convenient to use and find out what new functionality is needed. Here is very simple example in asm of simple bump-pointer allocation helper's "fast path" for windows: Incoming params: vtable, size Result - a new object reference. main: mov ecx, fs:[14h] // access to TLS mov eax, [ecx + current] // access to 'current' field add eax, size // check if there is enough size to do allocation in thread local buffer cmp eax, [ecx + ceiling] jg slow fast: mov [ecx+current], eax // save new 'current' sub eax, size// reposition to the start of the object mov [eax], vtable // save type info mov objRef eax // save or return result slow: call real new obj helper.. Even this simple helper reveals a lot of features to support: 1) Access to TLS is required. It could be fs:[14h] on Windows or helper call on Linux (depends on kernel (?) ). Even if we have an access to TLS we need to know the offsets of our slots: 'current' and 'ceiling' in example. So we need to have a way to pass these values to JIT. May be a 'private static final' variables in the helper's class with special runtime annotations could be used to pass the values to JIT? 2) Calls support is needed. Both for "slow" helper version and to access TLS. This means also that calling convention support is needed. Runtime level annotations for helper calls could be used here. E.g. create a magic method 'slow_alloc' and teach JIT to call real helper instead of it. Get the calling convention info from annotation (?) 3) Do we really want to expose native regs to Java: EAX, ECX... I vote do not to use them when writing helpers in Java and to allow to JIT to optimize unboxed operations (allocate registers by itself) So, there are a lot of questions to discuss before we can use the code like Alex did (http://issues.apache.org/jira/browse/HARMONY-816) to write this simple helper :) -- Mikhail Fursov
Re: [general] compatibility packages
Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 01:35:34PM +0100, Tim Ellison wrote: >> Dalibor Topic wrote: >>> On Thu, Aug 10, 2006 at 10:27:42AM +0100, Tim Ellison wrote: Mikhail Loenko wrote: > The problem is Base64 functionality is unavailable through the > standard API, so people have a choice either use unportable sun.*, > o.a.h.*, etc or create the coder from scratch Understood, I think people are 'driven' to using the non-API types though necessity rather than doing so by mistake. >>> Hardly. Many replacements for Base64 exists, for example GNU Classpath >>> recommends using Apache Commons Codec for projects compatible with the >>> Apache license. >>> >>> Amateur developers use non-standard classes because they are too lazy >>> to think for themselves, and accordingly copy broken code around projects. >>> Alas, a language designed to appeal to the masses naturally attracts a >>> lot of people who'd have trouble producing portable code in any programming >>> language. :) >> I was being charitable. For sure many such usages can be easily >> avoided, but in other cases no so easily; like CharToByteConverter would >> require duplicating a wad of data, and I don't know of any third-party >> impl. of Unsafe. > > Is there something that CharToByteConverter does that > CharsetEncoder(ICU) can't? I don't think there is, but I haven't seen > code using CharToByteConverter in years. If you want to duplicate the char conversion data then sure, but taking a multi-MB hit isn't palatable to many apps when sun.io is sitting there smiling at them. I saw a few uses when testing apps, but maybe I was unlucky. For example, Xalan was using it until it was pointed it out last year (http://issues.apache.org/jira/browse/XALANJ-2087). > Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks > to the JVM JSR not being ahead thinking enough to specify an API for > low-level > operations. It may or may not work depedending on how a VM interprets > the non-existent spec for that class, so it is practically useless, > unless it is running on the VM it was written on, i.e. Sun's. It may or > may not work by chance, rather than by virtue. > > That holds in general for any code using implementation-specific > interfaces. Exactly. >> We should appeal to app developers to change implementation dependent >> code (even provide a recipe book of recommended solutions), but be >> pragmatic about the need to run the current version. In many cases it >> may be beyond the apps immediate sphere of influence (i.e. dependent >> libraries). If everyone responded as quickly and effectively as Martin >> we would have no worries. > > We've been doing that for years. See the GNU Classpath migration page in > the Wiki that describes how to fix such broken code in many cases. Ack -- I see it here (just so others can find it too). http://developer.classpath.org/mediation/ClasspathMigration > Being 'pragmatic' solves nothing, it just encourages people to > continue behaving in dumb ways, because their code still may run, > somehow, even if there is no way for Harmony to ensure that it will > behave as they expect from whatever buggy Sun JDK they are using to > run it usually in the corner cases, because there is no spec, and > there are no tests. It's pragmatic because as I said, sometimes it is beyond the immediate control of the application, and sometimes you won't get a second chance to demonstrate your wares. 'Harmony - runs fewer apps than the leading brand' is hardly a compelling tag line. I believe that everyone wants to reduce dependencies on the non-API types. It is a millstone for IBM and Sun and BEA etc if they cannot modify their implementations without customers coming down on them. But at this point we cannot call the shots from Harmony. > Awarding incompetence doesn't solve the problem. That being said, kudos > to Martin for fixing the bug in his code. Had we had a Base64 class, > that bug wouldn't have showed up, and his code would have failed > elsewhere, or behaved differently on another VM. With the fix, his code > is portable, behaves in the same way on any VM, and may even be faster > than a vm-specific 'just for compatibility' implementation. > > There is no downside to simply fixing the buggy code. I agree, of course. >>> On a side note, I seem to recall reading on Sun's javac engineer's blog >>> that javac won't allow access to sun internal classes sooner or later, >>> so idiot-proofing class libraries may not be very useful, anyway, >>> as people will have to rewrite such code, or preferrably, throw it away. >> It will be interesting to see what havoc is unleashed by attempts to >> reduce the visibility of sun internal packages by the compiler and at >> runtime. > > I assume it will just cause unmaintained libraries to be substituted by > maintained ones, as people trade up to higher quality implementations of > functionality they need. Code that uses
Re: [general] *.boot.class.path propoerty setting
Geir Magnusson Jr wrote: > I was going to talk about the exact thing when I had a chance, so glad > you beat me to it. I'm just changing the subject line so it's clearer. > > Inline. > > Alexey Varlamov wrote: >> A bit offttopic for this thread, but I'd like to discuss the following >> points for the boot.class.path property: >> 1) Whose responsibility is to set this property (launcher, VM or >> classlib)? Now we have at least 3 implementations: >> a) readClassPathFromPropertiesFile() in >> classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c >> b) readClassPathFromPropertiesFile() in >> classlib\modules\luni\src\main\native\luni\shared\luniglob.c >> c) load_full_api_files_path_names_list() in >> drlvm\vm\vmcore\src\init\properties.cpp >> BTW, the first 2 seems to be just copy-paste copies. I believe there >> should be just single agent doing this task, most natural candidate is >> shared VM launcher. > > I also thought the launcher was the right place, but not so sure, as you > wouldn't want to handcuff the VM implementations as to what kinds of > features they can add here. Maybe VM launcher sets it originally, but > the VM is free to override? Not in the launcher, it has to be set for any application that calls JNI_CreateJavaVM. >> 2) Current parsers of the bootclasspath.properties are fragile in >> relation to format of this file: the file must end with line delimiter >> and must have strict platform line delimiters, otherwise jvm just >> hangs. Should I file new JIRA or this is intentional? > > Please file a JIRA. Hanging can never be intentional. :) Agreed, create JIRAs for these problems. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
I think I've fixed this a few days ago and attached the patch to JIRA. See
my emails in this thread. Does it fix the problem with verifier for you?
The problem with verifier is only the first one with activemq. After I fixed
the exception problem the app still didn't start up.
2006/8/11, Vladimir Ivanov <[EMAIL PROTECTED]>:
Seems, that drlvm rejects valid code when 'end_pc' value for exception
handler is equal to code array length.
At least, when I update value for 'end_pc' in my simple class it was
rejected by drlvm and accepted by RI.
Thanks, Vladimir
More details:
2 class attached: test.class.ref - generated by javac,
test.class - updated (line 108 for file belove was updated: 8 -> 10)
- test.code
/**
* Generated ccode file
* @author VMTT (Virtual Machine Testing Tools)
* @version 1.0
* @lastmod: Fri Aug 11 11:20:30 NOVST 2006
*/
magic = xCAFEBABE
minor_version = 0
major_version = 48
constant_pool_count = 18
constant_pool {
/* #1 */ Method = #5 #14
/* #2 */ Class = #15
/* #3 */ Method = #2 #14
/* #4 */ Class = #16
/* #5 */ Class = #17
/* #6 */ UTF8 = ""
/* #7 */ UTF8 = "()V"
/* #8 */ UTF8 = "Code"
/* #9 */ UTF8 = "LineNumberTable"
/* #10 */ UTF8 = "main"
/* #11 */ UTF8 = "([Ljava/lang/String;)V"
/* #12 */ UTF8 = "SourceFile"
/* #13 */ UTF8 = "test.java"
/* #14 */ NameAndType = #6 #7
/* #15 */ UTF8 = "java/lang/Exception"
/* #16 */ UTF8 = "test"
/* #17 */ UTF8 = "java/lang/Object"
}
access_flags = PUBLIC SUPER // x21
this_class = #4 // "test"
super_class = #5 // "java/lang/Object"
interfaces_count = 0
interfaces {
}
fields_count = 0
methods_count = 2
methods {
method {
access_flag = PUBLIC // x01
name_index = #6 // ""
descriptor_index = #7 // "()V"
attributes_count = 1
attributes {
attribute Code {
attribute_name_index = #8 // "Code"
attribute_length = 29
max_stack = 1
max_locals = 1
code_length = 5
code asm {
0: aload_0
1: invokespecial #1 // "java/lang/Object" "" "()V"
4: return
}
exception_table_length = 0
attributes_count = 1
attributes {
attribute LineNumberTable {
attribute_name_index = #9 // "LineNumberTable"
attribute_length = 6
line_number_table_length = 1
line_number_table {
// start_pc line_number
0 1
}
}
}
}
}
}
method {
access_flag = PUBLIC STATIC // x09
name_index = #10 // "main"
descriptor_index = #11 // "([Ljava/lang/String;)V"
attributes_count = 1
attributes {
attribute Code {
attribute_name_index = #8 // "Code"
attribute_length = 50
max_stack = 2
max_locals = 2
code_length = 10
code asm {
0: new #2 // "java/lang/Exception"
3: dup
4: invokespecial #3 // "java/lang/Exception" "" "()V"
7: athrow
8: astore_1
9: return
}
exception_table_length = 1
exception_table {
// start_pc end_pc handler_pc catch_type
0 10 8 2
}
attributes_count = 1
attributes {
attribute LineNumberTable {
attribute_name_index = #9 // "LineNumberTable"
attribute_length = 14
line_number_table_length = 3
line_number_table {
// start_pc line_number
0 4
8 5
9 7
}
}
}
}
}
}
}
attributes_count = 1
attributes {
attribute SourceFile {
attribute_name_index = #12 // "SourceFile"
attribute_length = 2
sourcefile_index = #13 // "test.java"
}
}
---
Output:
C:\tmp\vm_tool>java -showversion test
java version "1.4.2_10"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
C:\tmp\vm_tool>C:\jdk1.5.0_06\bin\java -showversion test
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05 , mixed mode)
C:\tmp\vm_tool>C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java
-Dvm.assert_dialog=false -cp . -showversion test
java version "1.5.0"
pre-alpha : not complete or compatible
svn = r430643, (Aug 11 2006), Windows/ia32/msvc 1310, debug build
http://incubator.apache.org/harmony
vf_debug: VerifyError: (class: test, method: main([Ljava/lang/String;)V)
Handler pc is out of range
java.lang.VerifyError: (class: test, method: main([Ljava/lang/String;)V)
Handler pc is out of range
at ja
Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
2006/8/11, Jimmy, Jing Lv <[EMAIL PROTECTED]>: Hi, As discussed in the former thread, I find that a JNI of DRLVM (GetByteArrayRegion) differs from RI in passing parameter (byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM throws an ArrayIndexOutOfBoundsException. IMHO, it is better to improve here, make it follow RI, as JNI is also a part of API, and users may use it. So if no objections, shall I or someone raise a JIRA for this? I don't know if Martin is urgent in using Harmony in Winstone servlet engine (Martin, can you read this?), so shall I work around in java code before we have conclusion? Any comments/suggestions from DRLVM guys? Thanks! I didn't really understand the condition when vm throws AIOBE. Do you pass start parameter count for the array of count length? But in this case the start points to the element right after the array end. And spec [1] explicitly states that this function should throw AIOBE in this case. Is there something I don't understand? [1] http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/functions.html#wp6212 -- Gregory Shimansky, Intel Middleware Products Division
Re: [classlib] [ldap] support for multiple VMs?
Tim Ellison wrote: Daniel Gandara wrote: Hi all, We are working on the javax.naming.ldap and we are facing the following issue when thinking about supporting multiple VMs. Following the SPEC there is a method createExtendedResponse in the StartTlsRequest class which states that the returning object must be an instance of a concrete subclass of StartTlsResponse and must have a public zero-argument constructor. The concrete subclass is determined by reading the configuration file located in META-INF/services/javax.naming.ldap.StartTlsResponse (see http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) The search for this configuration file is done by looking in the classpath, java.home and user.dir; also the Xbootclasspath should be inspected, and that seems to be a problematic situation, since there is not a standard property to look for its value. Different VM implementations have different property names for the boot class path value. In the old Harmony VM implementation was com.ibm.oti.system.class.path; in the new one is org.apache.harmony.boot.class. The property name in the Sun's VM is sun.boot.class.path. We are wondering which property name to use in the code. At first sight the Harmony new VM implementation property seems to be the better option, but maybe looking for the other properties will be interesting for compatibility purposes. We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? our goal is Harmony, but within our development and test procedure, we do check against the RI, just to be sure our code is working ok. It's not something that we would require for including the LDAP code in Harmony. :) next week we'll contribute the code for some classes that were missing from 1.4 version of javax.naming.ldap, and after that we'll send code for the 1.5 classes of the package. Thanks, Daniel Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[tools] Re: Keytool is done, JarSigner is next.
1) YAY! 2) No objections for jarsigner, but rather thanks and encouragement! 3) You may have been doing the following and I simply missed it, but I'd suggest that you keep a stream of patches coming on things like this so that people can see and get involved and also discuss more of your experience doing this on the list as it happens. 4) Can you add [tools] to your subject lines? :) geir Anton Rusanov wrote: > I'm happy to write this - Keytool is done and operative now. :) > It has the same functionality as the one from RI with some improvements. > In addition to what RI can do the Harmony Keytool is able to > * generate X.509 certificates v2, v3. > * sign a certificate with another key from the keystore > * generate and manage secret keys > * convert a keystore to another format > * check certificate revocation status > * verify a certificate chain > * use specific providers for various purposes. > > There is still a little problem with making an executable of the tool > in the build. So you can follow the steps to make it on your own: > 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe > 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ > 3. run keytool.exe > > I want to thank Mikhail for applying my patches. > I'm going to start work on JarSigner tool. Does anyone have objections > to me doing this? > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Winstone servlet engine fixed to run on Harmony
Martin Cordova wrote: > The author of Winstone detected the problem that generated an > exception when running on Harmony and fixed it the same day. > > My first impressions: Harmony JRE snapshot is fast. All database I/O > code from my webapp did run fine, as well as all network I/O. I could > not test PDF (IText) and Charts (JFreeChart) creation because certain > Image classes are not implemented yet. I will as soon as they become > available. That's really great to hear! > > My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support > for server sockets. > > I will keep you informed. > That's for doing this :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[general] *.boot.class.path propoerty setting (Was Re: [classlib] [ldap] support for multiple VMs?)
I was going to talk about the exact thing when I had a chance, so glad you beat me to it. I'm just changing the subject line so it's clearer. Inline. Alexey Varlamov wrote: > A bit offttopic for this thread, but I'd like to discuss the following > points for the boot.class.path property: > 1) Whose responsibility is to set this property (launcher, VM or > classlib)? Now we have at least 3 implementations: > a) readClassPathFromPropertiesFile() in > classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c > b) readClassPathFromPropertiesFile() in > classlib\modules\luni\src\main\native\luni\shared\luniglob.c > c) load_full_api_files_path_names_list() in > drlvm\vm\vmcore\src\init\properties.cpp > BTW, the first 2 seems to be just copy-paste copies. I believe there > should be just single agent doing this task, most natural candidate is > shared VM launcher. I also thought the launcher was the right place, but not so sure, as you wouldn't want to handcuff the VM implementations as to what kinds of features they can add here. Maybe VM launcher sets it originally, but the VM is free to override? > > 2) Current parsers of the bootclasspath.properties are fragile in > relation to format of this file: the file must end with line delimiter > and must have strict platform line delimiters, otherwise jvm just > hangs. Should I file new JIRA or this is intentional? Please file a JIRA. Hanging can never be intentional. :) geir > > > 2006/8/11, Tim Ellison <[EMAIL PROTECTED]>: >> Daniel Gandara wrote: >> > Hi all, >> > >> > We are working on the javax.naming.ldap and we are facing the >> > following issue when thinking about supporting multiple VMs. >> > Following the SPEC there is a method createExtendedResponse in the >> > StartTlsRequest class which states that the returning object must be >> > an instance of a concrete subclass of StartTlsResponse and must have >> > a public zero-argument constructor. The concrete subclass is >> > determined by reading the configuration file located in >> > META-INF/services/javax.naming.ldap.StartTlsResponse (see >> > >> http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) >> >> > >> > The search for this configuration file is done by looking in the >> > classpath, java.home and user.dir; also the Xbootclasspath should be >> > inspected, and that seems to be a problematic situation, since there >> > is not a standard property to look for its value. Different VM >> > implementations have different property names for the boot class path >> > value. In the old Harmony VM implementation was >> > com.ibm.oti.system.class.path; in the new one is >> > org.apache.harmony.boot.class. The property name in the Sun's VM is >> > sun.boot.class.path. We are wondering which property name to use in >> > the code. At first sight the Harmony new VM implementation property >> > seems to be the better option, but maybe looking for the other >> > properties will be interesting for compatibility purposes. >> > >> > We would be very interested in opinions. >> >> I'd ignore the com.ibm property and look through the path defined by >> org.apache.harmony.boot.class.path >> >> I don't know what property is set by the DRLVM / JCHEVM / etc., but it >> would be good if they set the same property (maybe in addition to their >> current property). >> >> If you want the code to run on the Sun implementation too then you >> should *also* search the sun.boot.class.path, and of course be tolerant >> of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal >> for you? It's not something that we would require for including the >> LDAP code in Harmony. >> >> Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
I'll add something on the site today, and put notes in the JRE. I'll also add language to point win2k users to the IBM JRE, but we won't publish a snapshot using it - we not only don't have the rights, I think it's safe to say that we don't want to. I'll remove DRLVM from the HDK to make it an easier drop in though, that should help. geir Paulex Yang wrote: > Before we get an agreement and solution on this issue, I suggest we add > some words on it in FAQ/Readme/website or any well known place, it is > much better to let our user know earlier than let them down. And because > IBM VME can run on Win2k for now, how about we provide it as a > workaround for those who are eager to try Harmony on win2k? > > Paulex Yang wrote: >> Just FYI if you haven't seen it, seems yet another win2k user was >> complaining on this. >> >> Radek Terber (JIRA) wrote: >>> Cannot run 'java.exe' - missing entry point in KERNEL.dll >>> - >>> >>> Key: HARMONY-1145 >>> URL: http://issues.apache.org/jira/browse/HARMONY-1145 >>> Project: Harmony >>> Issue Type: Bug >>> Components: VM >>> Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 >>> (both HDK and JRE) >>> Reporter: Radek Terber >>> Attachments: errmsg.gif >>> >>> When try start JRE using 'java.exe', windows display message (is >>> attached to this bug), which means: 'Entry point of procedure >>> AddVectorExceptionHandler not found in dynamic link libryry >>> KERNEL32.dll' >>> >>> >> >> > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][String] Request for fixing bug in String(byte[] bytes, int offset, int length, String charsetName)
Never worry if there will be an objection to you raising a JIRA and
providing a patch.Just Do It!
:)
geir
Richard Liang wrote:
> Hello All,
>
> The constructor "String(byte[] bytes, int offset, int length, String
> charsetName)" has the same bug as Harmony-487[1]. When the charsetName
> is "", RI throws UnsupportedEncodingException, but Harmony throws
> IllegalCharsetNameException.
>
> If there is no objection, I will raise a JIRA and provide a patch for
> this issue. Thanks a lot.
>
> The following test passes on RI, but fails on Harmony:
>try {
>String str = new String(new byte[] {0x41, 0x42}, 0, 2, "");
>fail("Should throw UnsupportedEncodingException");
>} catch (UnsupportedEncodingException e) {
>//expected
>}
>
> [1]http://issues.apache.org/jira/browse/HARMONY-487
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] HARMONY-956 - problem w/ DRLVM classloader
Nice. Have a patch? :)
geir
Vladimir Ivanov wrote:
> Seems, that drlvm rejects valid code when 'end_pc' value for exception
> handler is equal to code array length.
> At least, when I update value for 'end_pc' in my simple class it was
> rejected by drlvm and accepted by RI.
>
> Thanks, Vladimir
>
> More details:
> 2 class attached: test.class.ref - generated by javac,
> test.class - updated (line 108 for file belove was updated: 8 -> 10)
> - test.code
>
> /**
> * Generated ccode file
> * @author VMTT (Virtual Machine Testing Tools)
> * @version 1.0
> * @lastmod: Fri Aug 11 11:20:30 NOVST 2006
> */
>
> magic = xCAFEBABE
>
> minor_version = 0
>
> major_version = 48
>
> constant_pool_count = 18
>
> constant_pool {
> /* #1 */ Method = #5 #14
> /* #2 */ Class = #15
> /* #3 */ Method = #2 #14
> /* #4 */ Class = #16
> /* #5 */ Class = #17
> /* #6 */ UTF8 = ""
> /* #7 */ UTF8 = "()V"
> /* #8 */ UTF8 = "Code"
> /* #9 */ UTF8 = "LineNumberTable"
> /* #10 */ UTF8 = "main"
> /* #11 */ UTF8 = "([Ljava/lang/String;)V"
> /* #12 */ UTF8 = "SourceFile"
> /* #13 */ UTF8 = "test.java"
> /* #14 */ NameAndType = #6 #7
> /* #15 */ UTF8 = "java/lang/Exception"
> /* #16 */ UTF8 = "test"
> /* #17 */ UTF8 = "java/lang/Object"
> }
>
> access_flags = PUBLIC SUPER // x21
>
> this_class = #4 // "test"
>
> super_class = #5 // "java/lang/Object"
>
> interfaces_count = 0
>
> interfaces {
> }
>
> fields_count = 0
>
> methods_count = 2
>
> methods {
> method {
>access_flag = PUBLIC // x01
>name_index = #6 // ""
>descriptor_index = #7 // "()V"
>attributes_count = 1
> attributes {
>attribute Code {
> attribute_name_index = #8 // "Code"
> attribute_length = 29
> max_stack = 1
> max_locals = 1
> code_length = 5
> code asm {
> 0: aload_0
> 1: invokespecial #1 // "java/lang/Object" "" "()V"
> 4: return
> }
> exception_table_length = 0
> attributes_count = 1
>attributes {
> attribute LineNumberTable {
>attribute_name_index = #9 // "LineNumberTable"
>attribute_length = 6
>line_number_table_length = 1
>line_number_table {
>// start_pc line_number
>0 1
>}
> }
>}
>}
> }
> }
> method {
>access_flag = PUBLIC STATIC // x09
>name_index = #10 // "main"
>descriptor_index = #11 // "([Ljava/lang/String;)V"
>attributes_count = 1
> attributes {
>attribute Code {
> attribute_name_index = #8 // "Code"
> attribute_length = 50
> max_stack = 2
> max_locals = 2
> code_length = 10
> code asm {
> 0: new #2 // "java/lang/Exception"
> 3: dup
> 4: invokespecial #3 // "java/lang/Exception" "" "()V"
> 7: athrow
> 8: astore_1
> 9: return
> }
> exception_table_length = 1
> exception_table {
>// start_pc end_pc handler_pc catch_type
>0 10 8 2
> }
> attributes_count = 1
>attributes {
> attribute LineNumberTable {
>attribute_name_index = #9 // "LineNumberTable"
>attribute_length = 14
>line_number_table_length = 3
>line_number_table {
>// start_pc line_number
>0 4
>8 5
>9 7
>}
> }
>}
>}
> }
> }
> }
>
> attributes_count = 1
> attributes {
> attribute SourceFile {
>attribute_name_index = #12 // "SourceFile"
>attribute_length = 2
>sourcefile_index = #13 // "test.java"
> }
> }
> ---
>
> Output:
>
> C:\tmp\vm_tool>java -showversion test
> java version "1.4.2_10"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_10-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_10-b03, mixed mode)
>
>
> C:\tmp\vm_tool>C:\jdk1.5.0_06\bin\java -showversion test
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
>
>
> C:\tmp\vm_tool>C:\harmony\drlvm1.5\build\win_ia32_msvc_debug\deploy\jre\bin\java
>
> -Dvm.assert_dialog=false -cp . -showversion test
> java version "1.5.0"
> pre-alpha : not complete or compatible
> svn = r430643, (Aug 11 2006), Windows/ia32/msvc 1310, debug build
> http://incubator.apache.org/harmony
> vf_debug: VerifyError: (class: test, method: main([Ljava/lang/String;)V)
> Handler pc is out of range
> java.lang.VerifyError: (class: test, method: main([Ljava/lang/String;)V)
> Handler pc is out of range
>at java.lang.VMClassRegistry.defineC
Re: [classlib][suncompat] created
Salikh Zakirov wrote: > If we do not include suncompat.jar into classpath at compile > time, rather than runtime, then the users will get > the feedback at approprate moment of time. > > So, I would suggest > + include suncompat.jar to runtime classpath by default > - do *not* include suncompat.jar to compile-time classpath by default That's a very nice solution. None of the arguments have swayed me about not having it at runtime because while I agree that it's bad practice, our biggest interest *at this time* is to get users, because users are going to be an enormous help in finding bugs, prioritizing what we are working on, etc. And removing every speedbump in the road to using harmony is going to help that. We will be in a great position to help people stop this misbehavior, as *when they are interested*, they can simply remove suncompat easily and quickly due to our great modularity... I think we can use this problem to our advantage... geir > > Geir Magnusson Jr wrote: >> Oh - definitely only add as needed, and yes, we need to have good >> documentation to assist users. >> >> And I'm very +1 about including this by default for now. See other >> threads as for why. > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][suncompat] created
Nathan Beyer wrote: > I agree, let's just enable it by default. I would suggest that we tag all of > these classes as @Deprecated with a nice message saying you really shouldn't > be using this. > I've had some private musings of also getting those classes to log to some kind of "your_code_is_broken.log" but that's just early morning crazy talk. geir > -Nathan > >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Thursday, August 10, 2006 11:13 AM >> To: harmony-dev@incubator.apache.org >> Subject: Re: [classlib][suncompat] created >> >> Oh - definitely only add as needed, and yes, we need to have good >> documentation to assist users. >> >> And I'm very +1 about including this by default for now. See other >> threads as for why. >> >> geir >> >> Alex Blewitt wrote: >>> Sounds like a FAQ in the making :-) >>> >>> On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Alex Blewitt wrote: > OK. What's the plan with regards to adding items in here e.g. Base64 > or tools like JavaC? Or do we just add them organically as we find > problems? Let's try and keep this JAR as small as possible, only adding types after a debate on the list concludes that it is a 'necessity'. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] >>> - >>> Terms of use : http://incubator.apache.org/harmony/mailing.html >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
I think we should just fix it in DRLVM, although performance-wise,
wouldn't also fixing in Java make sense too?
As Tim said, raise a JIRA.
geir
Jimmy, Jing Lv wrote:
> Hi,
>
> As discussed in the former thread, I find that a JNI of DRLVM
> (GetByteArrayRegion) differs from RI in passing parameter
> (byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
> throws an ArrayIndexOutOfBoundsException.
> IMHO, it is better to improve here, make it follow RI, as JNI is
> also a part of API, and users may use it. So if no objections, shall I
> or someone raise a JIRA for this?
>
> I don't know if Martin is urgent in using Harmony in Winstone
> servlet engine (Martin, can you read this?), so shall I work around in
> java code before we have conclusion?
>
> Any comments/suggestions from DRLVM guys? Thanks!
>
>
> Jimmy, Jing Lv wrote:
>> Jimmy, Jing Lv wrote:
>>>
>>>
>>> I do some further study and test then, and find the problem was not
>>> so easy.
>>>
>>> Alex and I are correct that "offset <= buffer.length" here is wrong,
>>> but the next "count <= buffer.length - offset" seems has proved its
>>> correctness.
>>>
>>> I have a test[1], try to write(new byte[count],count, 0) to a
>>> SocketOutputStream, the test passes quietly. I do this test on WinXp
>>> Sp2, the latest Harmony workspace, with J9 VM5.
>>>
>>> I believe the ArrayIndexOutOfBoundsException is throw out when it try
>>> to get byte array in the native (GetByteArrayRegion), which is a JNI
>>> method. I guess there may be some difference between VMs.
>>>
>>> Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
>>> run the test below on DRLVM for me? Thanks!
>>>
>>> [1]
>>> public void test_socketOutputStream() throws Exception {
>>> ServerSocket ss = new ServerSocket(0);
>>> Socket sock = new Socket();
>>> sock.connect(new InetSocketAddress
>>>(InetAddress.getLocalHost(),ss.getLocalPort()));
>>> ss.accept();
>>> OutputStream os = sock.getOutputStream();
>>> os.write(new byte[0], 0, 0); // passes here
>>> os.write(new byte[512], 512, 0); // passes here
>>> }
>>>
>>
>> Hi,
>>
>> At last I have test[1] JNI method(GetByteArrayRegion) of RI
>> (before dinner, very hungry... :) )
>> The result is that, RI return successfully if the given offset
>> equals length of the byte array, and the given count is zero.
>>
>> Thus IMHO it is better to improve DRLVM to follow RI, as JNI
>> methods are also API methods, users may use it.
>>
>> Shall we raise a JIRA for DRLVM? Any comments/suggestions from
>> DRLVM guys? Thanks!
>>
>> Time for dinner! :D
>>
>> [1]
>> test.java
>> --
>> class test
>> {
>> static{
>> System.loadLibrary("testjni");
>> }
>>private native void testjni(byte[] bs);
>> public void usejni(){
>> testjni(new byte[512]);
>> }
>> public static void main(String args[]){
>> new test().usejni();
>> }
>> }
>> ---
>> test.h
>> ---
>> /* DO NOT EDIT THIS FILE - it is machine generated */
>> #include
>> /* Header for class test */
>>
>> #ifndef _Included_test
>> #define _Included_test
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> /*
>> * Class: test
>> * Method:testjni
>> * Signature: ([B)V
>> */
>> JNIEXPORT void JNICALL Java_test_testjni
>> (JNIEnv *, jobject, jbyteArray);
>>
>> #ifdef __cplusplus
>> }
>> #endif
>> #endif
>> --
>> test.c
>> --
>> #include "test.h"
>> JNIEXPORT void JNICALL Java_test_testjni
>> (JNIEnv * env, jobject obj,jbyteArray array){
>> jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
>> (*env)->GetByteArrayRegion(env,array,512, 0, buf);
>> }
>>
>> (magic number 512 can be any integer, including zero)
>>
>>
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]Method to terminate VM.
How far along is this code? Any chance you want to toss up a snapshot of it so people can look and comment and ... maybe even help? geir Jimmy, Jing Lv wrote: > Leo Li wrote: >> Hi, all >> During the implementaion of instrument, I encounter the choice about >> how to terminate the VM when some abnormal event occurs, for example, the >> expected jar file does not exist or the implementation class of >> Instrumentation cannot be found. The most simple and direct way is >> just to >> call exit(), and then the whole process will terminate. Hence OS will >> treat >> with all the release of resources. However, I propose to use >> FatalError of >> JNI instead, which notifies the VM to suicide, because it gives right >> to the >> implementation of VM to take charge of its own funeral affairs, which >> might >> include, for example, logging the cause of its crash. >>Any suggestion from VM guys? >>Thanks :) >> > > Hi, > > I agree that use VM FatalError is better than system exit(). If no > objections, I will make code that way. > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] compatibility packages
Dalibor Topic wrote: > On Thu, Aug 10, 2006 at 12:01:32PM -0400, Geir Magnusson Jr wrote: >> >> Dalibor Topic wrote: >>> >>> Code using Unsafe, of course, is fundamentally tied to a VM, anyway, thanks >>> to the JVM JSR not being ahead thinking enough to specify an API for >>> low-level >>> operations. It may or may not work depedending on how a VM interprets >>> the non-existent spec for that class, so it is practically useless, >>> unless it is running on the VM it was written on, i.e. Sun's. It may or >>> may not work by chance, rather than by virtue. >> I think you are being too harsh here, but that notwithstanding, one of >> the things we can do as open implementations is petition the EG to >> actually define these in the spec once we show that there's a good >> reason to do so, namely the independent implementations. > > The independant implementations are not using sun.misc.Unsafe. Why would > anyone want to use an undocumented implementation-specific class from > another implementation in their own? That makes no sense. There is no > point in petitioning the EC to specify sun.misc.Unsafe since no one in > their right mind uses it, except Sun, in the interna of their > implementation. That's like asking the EC to specify org.kaffe.util.Ptr, > or something equivalently pointless from DLRVM. It makes sense if you wish to use Doug's concurrency package as-is, as it has dependencies on sun.misc.Unsafe, which I think is a Good Thing. After we do that, I think we then go back to the EG and point out that in order for the world to reuse this code, we need to have sun.misc.Unsafe defined (of course, it would be given another namespace...). > > What I want is a java.util.concurrent.VMCompareAndSwap class in j.u.c, > with a sane API that does not require computing field offsets manually, > like sun.misc.Unsafe seems to do. ;) That would a good thing to ask for two - the two would make a nice request. > > The only reason why sun.misc.Unsafe matters for us is, IMHO, a rather > simple bug in Doug Lea's java.util.concurrent implementation: using > Sun-specific classes directly, rather than delegating to some > java.util.concurrent.VMCompareAndSwap interface layer. That means anyone > adopting the code needs to repeat the mistakes of Sun's implementation > (which has, coincidentally, had a very straightforward remote execution > exploit involving direct use of sun.misc.Unsafe a while ago) or fork it. > > Yay. :/ > > Other than Doug's code, sun.misc.Unsafe does not matter at all, unless > you want "remote-execution-exploit-for-remote-execution-exploit" > compatibility. I believe that's too much to ask for. ;) I think we've been clear all along why we'd implement this - we want to use Doug's code. [SNIP] >> Sure, but again, not everyone will be as wise as Martin - they'll just >> bail on us. They may even realize that there's a problem with their >> code, but there may be nothing they can do about it. > > People bailing on us is not a problem, as people *stuck with Sun-specific > code* will > (and should, IMHO) only use Sun's VM anyway. People blindly trusting us > because > we pretend to run some Sun-specific code according to some unspecified > interface > is a problem, both for them, as their code will obviously behave differently > from > what it expects, in subtle ways, if they are very unlucky, and for us, as we > have > to chase unreproducible behaviour as Sun changes their internal > interfaces around. See the sad story of Ant's chasing around of > sun.tools.javac.Main tail over and over again. Oh, come on. You talk like the rest of the spec is rock solid and perfectly defined. We're spelunking the RI through black-box testing all the time in our drive to get full behavioral compatibility. Adding a few utility classes that people are unfortunately using - knowingly or unknowingly - is simply good customer service, IMO. > > The 'works 100% like Sun's VM out-of-the-box for Sun-specific code' niche is > already taken by Sun. There is no point in trying to compete with them on > that, > or for the audience that wants and expects that. Been there, done that, > etc. ;) I think we'll have to continue to disagree on this one. I do want Harmony to work 100% like Sun to start because we want users to be able to effortlessly transition to Harmony. Software is nothing without users. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keytool is done, JarSigner is next.
I'm happy to write this - Keytool is done and operative now. :) It has the same functionality as the one from RI with some improvements. In addition to what RI can do the Harmony Keytool is able to * generate X.509 certificates v2, v3. * sign a certificate with another key from the keystore * generate and manage secret keys * convert a keystore to another format * check certificate revocation status * verify a certificate chain * use specific providers for various purposes. There is still a little problem with making an executable of the tool in the build. So you can follow the steps to make it on your own: 1. copy deploy\jdk\jre\bin\java.exe to deploy\jdk\jre\bin\keytool.exe 2. copy deploy\jdk\lib\tools.jar into deploy\jdk\jre\bin\ 3. run keytool.exe I want to thank Mikhail for applying my patches. I'm going to start work on JarSigner tool. Does anyone have objections to me doing this? -- Thanks, Anton - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Winstone servlet engine fixed to run on Harmony
The author of Winstone detected the problem that generated an exception when running on Harmony and fixed it the same day. My first impressions: Harmony JRE snapshot is fast. All database I/O code from my webapp did run fine, as well as all network I/O. I could not test PDF (IText) and Charts (JFreeChart) creation because certain Image classes are not implemented yet. I will as soon as they become available. My pending tasks: test on Linux (OpenSuSE 10.0) and test SSL support for server sockets. I will keep you informed. Regards, Martin -- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
Hello,
Mess with golden files seem to be a problem. Why not just pass path to
an alternative JVM as an argument to the tests? Maybe an environment
variable or a VM property. The test framework can serialize some data
in one vm, deserialize it in another and check that object was
deserialized correctly. Process communication or serialization to
temporary files can be used to exchange data between VMs. This
approach will:
- remove golden files
- allow test that data serialized in Harmony is deserialized in
another VM correctly
- allow compare Harmony serialization with any VM, not only the one
used when golden files were produced.
The test based on such framework will look something like:
public void writeTestData(ObjectOutputStream oos) {
oos.write(new Integer(2));
}
public void readTestData(ObjectInputStream ois) {
Integer i = (Integer) ois.readObject();
assertEquals(i.intValue(), 2);
}
On 8/11/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
On 8/11/06, Mark Hindess wrote:
>
>
> On 10 August 2006 at 14:51, "Stepan Mishura" wrote:
> >
> > On 8/10/06, Jimmy, Jing Lv wrote:
> > >
> > > Hi Stepan,
> > >
> > > IMO, most ser file should be put into a certain directory, so
> > > the the appropriate directory is always there.
> > >
> > > I'd like to add a new method to the framework as:
> > >
> > > public static void createGoldenFile(TestCase test,Object object)
> > > throws IOException {
> > > createGoldenFile("src/test/resources/serialization",test,object);
> > > }
> >
> > But if 'root' param is relative path them the generated
> > file is placed in 'bin' (i.e. /bin/test).
> > folder. Am I right? So you have to move it by hands anyway to
> > /src/test/resources/serialization folder.
>
> I was thinking about this. Currently all of the relative paths in
> modules//build.xml are relative to modules/, except those
> on test invocations which are relative to modules//bin/test.
>
> IMHO, this is slightly confusing for instance in the security module,
> For example, modules/security/build.xml sets the classpath (in ant) to
> include
> "../../build/tests" when running the api tests, but when running the
> api injected tests it appends "../../../../build/tests" to the
> bootclasspath (using -X vm argument).
Yes, I agree that this is confusing and should be fixed.
Thanks,
Stepan.
I think ant should just run tests in modules/.
>
> (I didn't realise that eclipse already ran the tests for there or I'd
> probably have suggested it earlier.)
>
> Regards,
> Mark.
>
>
>
>
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [ldap] support for multiple VMs?
A bit offttopic for this thread, but I'd like to discuss the following points for the boot.class.path property: 1) Whose responsibility is to set this property (launcher, VM or classlib)? Now we have at least 3 implementations: a) readClassPathFromPropertiesFile() in classlib\modules\archive\src\main\native\archive\windows\jclglob_harmony.c b) readClassPathFromPropertiesFile() in classlib\modules\luni\src\main\native\luni\shared\luniglob.c c) load_full_api_files_path_names_list() in drlvm\vm\vmcore\src\init\properties.cpp BTW, the first 2 seems to be just copy-paste copies. I believe there should be just single agent doing this task, most natural candidate is shared VM launcher. 2) Current parsers of the bootclasspath.properties are fragile in relation to format of this file: the file must end with line delimiter and must have strict platform line delimiters, otherwise jvm just hangs. Should I file new JIRA or this is intentional? 2006/8/11, Tim Ellison <[EMAIL PROTECTED]>: Daniel Gandara wrote: > Hi all, > > We are working on the javax.naming.ldap and we are facing the > following issue when thinking about supporting multiple VMs. > Following the SPEC there is a method createExtendedResponse in the > StartTlsRequest class which states that the returning object must be > an instance of a concrete subclass of StartTlsResponse and must have > a public zero-argument constructor. The concrete subclass is > determined by reading the configuration file located in > META-INF/services/javax.naming.ldap.StartTlsResponse (see > http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) > > The search for this configuration file is done by looking in the > classpath, java.home and user.dir; also the Xbootclasspath should be > inspected, and that seems to be a problematic situation, since there > is not a standard property to look for its value. Different VM > implementations have different property names for the boot class path > value. In the old Harmony VM implementation was > com.ibm.oti.system.class.path; in the new one is > org.apache.harmony.boot.class. The property name in the Sun's VM is > sun.boot.class.path. We are wondering which property name to use in > the code. At first sight the Harmony new VM implementation property > seems to be the better option, but maybe looking for the other > properties will be interesting for compatibility purposes. > > We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? It's not something that we would require for including the LDAP code in Harmony. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][suncompat] created
If we do not include suncompat.jar into classpath at compile time, rather than runtime, then the users will get the feedback at approprate moment of time. So, I would suggest + include suncompat.jar to runtime classpath by default - do *not* include suncompat.jar to compile-time classpath by default Geir Magnusson Jr wrote: > Oh - definitely only add as needed, and yes, we need to have good > documentation to assist users. > > And I'm very +1 about including this by default for now. See other > threads as for why. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Assigned: (HARMONY-1046) Remove jpegint.h from awt native sources
Sorry, Mark, I didn't mean to steal this closed one from you, I'm going to assign 1146 to myself... :-[ , more tea... Paulex Yang (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-1046?page=all ] Paulex Yang reassigned HARMONY-1046: Assignee: Paulex Yang (was: Mark Hindess) Remove jpegint.h from awt native sources Key: HARMONY-1046 URL: http://issues.apache.org/jira/browse/HARMONY-1046 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Petrenko Assigned To: Paulex Yang Priority: Minor Attachments: JIRA1046.diff AWT native jpeg encoder and decoder are using jpegint.h. But not all the jpeg library distributions has this header file. Evaluation shown that this file can be easily removed from the encoder and decoder. So we should do this. I'll prepare patch shortly. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
On 8/11/06, Mark Hindess wrote:
On 10 August 2006 at 14:51, "Stepan Mishura" wrote:
>
> On 8/10/06, Jimmy, Jing Lv wrote:
> >
> > Hi Stepan,
> >
> > IMO, most ser file should be put into a certain directory, so
> > the the appropriate directory is always there.
> >
> > I'd like to add a new method to the framework as:
> >
> > public static void createGoldenFile(TestCase test,Object object)
> > throws IOException {
> > createGoldenFile("src/test/resources/serialization",test,object);
> > }
>
> But if 'root' param is relative path them the generated
> file is placed in 'bin' (i.e. /bin/test).
> folder. Am I right? So you have to move it by hands anyway to
> /src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules//build.xml are relative to modules/, except those
on test invocations which are relative to modules//bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to
include
"../../build/tests" when running the api tests, but when running the
api injected tests it appends "../../../../build/tests" to the
bootclasspath (using -X vm argument).
Yes, I agree that this is confusing and should be fixed.
Thanks,
Stepan.
I think ant should just run tests in modules/.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Regards,
Mark.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: [classlib][suncompat] created
>-Original Message- >From: Oleg Khaschansky [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 2:32 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >Another solution is to create stubs which will throw exceptions with >detailed message. Then users will get neccessary information but >functionality won't be enabled by default. Good point! It's even better :) Regards, Alexey. > >On 8/11/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: >> I agree with Alex, we should *not* have this by default. Having it >> enabled by default will not give a hint something's wrong with the code. >> I believe no one will ever look in the sources if everything works just >> fine, and therefore no one will see the deprecation. >> At least, the new code won't reference these classes. However we'll >> provide a workaround to keep legacy applications running on Harmony in >> cases where the code can't be updated properly. >> >> When suncompat.jar is removed from the default distribution, people will >> be frustrated as well. >> >> Regards, >> -- >> Alexey A. Ivanov >> Intel Middleware Product Division >> >> >> >-Original Message- >> >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >> >Sent: Friday, August 11, 2006 12:06 PM >> >To: harmony-dev@incubator.apache.org >> >Subject: Re: RE: [classlib][suncompat] created >> > >> >I think the @deprecated is a good idea, but I strongly believe that we >> >should *not* have this as a default. There's an easy workaround for >> >the subset of applications that need it (e.g. enable it in the >> >.properties file) whilst still preventing new code from being able to >> >reference it. A simple FAQ should be enough to help people do this. >> > >> >Mind you, I seem to be in the minority on this view on this list :-) >> > >> >Alex. >> > >> >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> >> I agree, let's just enable it by default. I would suggest that we tag >> all >> >of >> >> these classes as @Deprecated with a nice message saying you really >> >shouldn't >> >> be using this. >> >> >> >> -Nathan >> >> >> >> > -Original Message- >> >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> >> > Sent: Thursday, August 10, 2006 11:13 AM >> >> > To: harmony-dev@incubator.apache.org >> >> > Subject: Re: [classlib][suncompat] created >> >> > >> >> > Oh - definitely only add as needed, and yes, we need to have good >> >> > documentation to assist users. >> >> > >> >> > And I'm very +1 about including this by default for now. See other >> >> > threads as for why. >> >> > >> >> > geir >> >> > >> >> > Alex Blewitt wrote: >> >> > > Sounds like a FAQ in the making :-) >> >> > > >> >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> >> > >> Alex Blewitt wrote: >> >> > >> > OK. What's the plan with regards to adding items in here e.g. >> >Base64 >> >> > >> > or tools like JavaC? Or do we just add them organically as we >> find >> >> > >> > problems? >> >> > >> >> >> > >> Let's try and keep this JAR as small as possible, only adding >> types >> >> > >> after a debate on the list concludes that it is a 'necessity'. >> >> > >> >> >> > >> Regards, >> >> > >> Tim >> >> > >> >> >> > >> -- >> >> > >> >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> >> > >> IBM Java technology centre, UK. >> >> > >> >> >> > >> >> >> >- >> >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> > >> For additional commands, e-mail: harmony-dev- >> >[EMAIL PROTECTED] >> >> > >> >> >> > >> >> >> > > >> >> > > >> - >> >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> > > For additional commands, e-mail: harmony-dev- >> >[EMAIL PROTECTED] >> >> > > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> - >> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> > To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> >> > For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> >> >> - >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> >> >> > >> >- >> >Terms of use : http://incubator.apache.org/harmony/mailing.html >> >To unsubscribe, e-mail: [EMAIL PROTECTED] >> >For additional commands, e-mail: [EMAIL PROTECTED] >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional
Re: RE: [classlib][suncompat] created
Another solution is to create stubs which will throw exceptions with detailed message. Then users will get neccessary information but functionality won't be enabled by default. On 8/11/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote: I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 12:06 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >I think the @deprecated is a good idea, but I strongly believe that we >should *not* have this as a default. There's an easy workaround for >the subset of applications that need it (e.g. enable it in the >.properties file) whilst still preventing new code from being able to >reference it. A simple FAQ should be enough to help people do this. > >Mind you, I seem to be in the minority on this view on this list :-) > >Alex. > >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> I agree, let's just enable it by default. I would suggest that we tag all >of >> these classes as @Deprecated with a nice message saying you really >shouldn't >> be using this. >> >> -Nathan >> >> > -Original Message- >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, August 10, 2006 11:13 AM >> > To: harmony-dev@incubator.apache.org >> > Subject: Re: [classlib][suncompat] created >> > >> > Oh - definitely only add as needed, and yes, we need to have good >> > documentation to assist users. >> > >> > And I'm very +1 about including this by default for now. See other >> > threads as for why. >> > >> > geir >> > >> > Alex Blewitt wrote: >> > > Sounds like a FAQ in the making :-) >> > > >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> Alex Blewitt wrote: >> > >> > OK. What's the plan with regards to adding items in here e.g. >Base64 >> > >> > or tools like JavaC? Or do we just add them organically as we find >> > >> > problems? >> > >> >> > >> Let's try and keep this JAR as small as possible, only adding types >> > >> after a debate on the list concludes that it is a 'necessity'. >> > >> >> > >> Regards, >> > >> Tim >> > >> >> > >> -- >> > >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> > >> IBM Java technology centre, UK. >> > >> >> > >> >- >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > >> For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > >> >> > >> >> > > >> > > - >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > > >> > > >> > > >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE: [classlib][suncompat] created
I agree with Alex, we should *not* have this by default. Having it enabled by default will not give a hint something's wrong with the code. I believe no one will ever look in the sources if everything works just fine, and therefore no one will see the deprecation. At least, the new code won't reference these classes. However we'll provide a workaround to keep legacy applications running on Harmony in cases where the code can't be updated properly. When suncompat.jar is removed from the default distribution, people will be frustrated as well. Regards, -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Alex Blewitt [mailto:[EMAIL PROTECTED] >Sent: Friday, August 11, 2006 12:06 PM >To: harmony-dev@incubator.apache.org >Subject: Re: RE: [classlib][suncompat] created > >I think the @deprecated is a good idea, but I strongly believe that we >should *not* have this as a default. There's an easy workaround for >the subset of applications that need it (e.g. enable it in the >.properties file) whilst still preventing new code from being able to >reference it. A simple FAQ should be enough to help people do this. > >Mind you, I seem to be in the minority on this view on this list :-) > >Alex. > >On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: >> I agree, let's just enable it by default. I would suggest that we tag all >of >> these classes as @Deprecated with a nice message saying you really >shouldn't >> be using this. >> >> -Nathan >> >> > -Original Message- >> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> > Sent: Thursday, August 10, 2006 11:13 AM >> > To: harmony-dev@incubator.apache.org >> > Subject: Re: [classlib][suncompat] created >> > >> > Oh - definitely only add as needed, and yes, we need to have good >> > documentation to assist users. >> > >> > And I'm very +1 about including this by default for now. See other >> > threads as for why. >> > >> > geir >> > >> > Alex Blewitt wrote: >> > > Sounds like a FAQ in the making :-) >> > > >> > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> > >> Alex Blewitt wrote: >> > >> > OK. What's the plan with regards to adding items in here e.g. >Base64 >> > >> > or tools like JavaC? Or do we just add them organically as we find >> > >> > problems? >> > >> >> > >> Let's try and keep this JAR as small as possible, only adding types >> > >> after a debate on the list concludes that it is a 'necessity'. >> > >> >> > >> Regards, >> > >> Tim >> > >> >> > >> -- >> > >> >> > >> Tim Ellison ([EMAIL PROTECTED]) >> > >> IBM Java technology centre, UK. >> > >> >> > >> >- >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> > >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> > >> For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > >> >> > >> >> > > >> > > - >> > > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > > For additional commands, e-mail: harmony-dev- >[EMAIL PROTECTED] >> > > >> > > >> > > >> > >> > >> > - >> > Terms of use : http://incubator.apache.org/harmony/mailing.html >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >Terms of use : http://incubator.apache.org/harmony/mailing.html >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
Mark Hindess wrote:
On 10 August 2006 at 14:51, "Stepan Mishura" <[EMAIL PROTECTED]> wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile("src/test/resources/serialization",test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. /bin/test).
folder. Am I right? So you have to move it by hands anyway to
/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules//build.xml are relative to modules/, except those
on test invocations which are relative to modules//bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to include
"../../build/tests" when running the api tests, but when running the
api injected tests it appends "../../../../build/tests" to the
bootclasspath (using -X vm argument).
I think ant should just run tests in modules/.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Great idea! :)
So Stepan will not object my method of createGolden, right? ;)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [ldap] support for multiple VMs?
Daniel Gandara wrote: > Hi all, > > We are working on the javax.naming.ldap and we are facing the > following issue when thinking about supporting multiple VMs. > Following the SPEC there is a method createExtendedResponse in the > StartTlsRequest class which states that the returning object must be > an instance of a concrete subclass of StartTlsResponse and must have > a public zero-argument constructor. The concrete subclass is > determined by reading the configuration file located in > META-INF/services/javax.naming.ldap.StartTlsResponse (see > http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/StartTlsRequest.html) > > The search for this configuration file is done by looking in the > classpath, java.home and user.dir; also the Xbootclasspath should be > inspected, and that seems to be a problematic situation, since there > is not a standard property to look for its value. Different VM > implementations have different property names for the boot class path > value. In the old Harmony VM implementation was > com.ibm.oti.system.class.path; in the new one is > org.apache.harmony.boot.class. The property name in the Sun's VM is > sun.boot.class.path. We are wondering which property name to use in > the code. At first sight the Harmony new VM implementation property > seems to be the better option, but maybe looking for the other > properties will be interesting for compatibility purposes. > > We would be very interested in opinions. I'd ignore the com.ibm property and look through the path defined by org.apache.harmony.boot.class.path I don't know what property is set by the DRLVM / JCHEVM / etc., but it would be good if they set the same property (maybe in addition to their current property). If you want the code to run on the Sun implementation too then you should *also* search the sun.boot.class.path, and of course be tolerant of o.a.harmony... or sun.boot... being absent. Is running on Sun a goal for you? It's not something that we would require for including the LDAP code in Harmony. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo "Better make changes in the teamplate file." -> template. Ilya Okomin wrote: > I would suggest to split this task into a set of jira sub-issues, one > module - one issue. This kind of division would give us an > opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
On 10 August 2006 at 14:51, "Stepan Mishura" <[EMAIL PROTECTED]> wrote:
>
> On 8/10/06, Jimmy, Jing Lv wrote:
> >
> > Hi Stepan,
> >
> > IMO, most ser file should be put into a certain directory, so
> > the the appropriate directory is always there.
> >
> > I'd like to add a new method to the framework as:
> >
> > public static void createGoldenFile(TestCase test,Object object)
> > throws IOException {
> > createGoldenFile("src/test/resources/serialization",test,object);
> > }
>
> But if 'root' param is relative path them the generated
> file is placed in 'bin' (i.e. /bin/test).
> folder. Am I right? So you have to move it by hands anyway to
> /src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules//build.xml are relative to modules/, except those
on test invocations which are relative to modules//bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to include
"../../build/tests" when running the api tests, but when running the
api injected tests it appends "../../../../build/tests" to the
bootclasspath (using -X vm argument).
I think ant should just run tests in modules/.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
Before we get an agreement and solution on this issue, I suggest we add some words on it in FAQ/Readme/website or any well known place, it is much better to let our user know earlier than let them down. And because IBM VME can run on Win2k for now, how about we provide it as a workaround for those who are eager to try Harmony on win2k? Paulex Yang wrote: Just FYI if you haven't seen it, seems yet another win2k user was complaining on this. Radek Terber (JIRA) wrote: Cannot run 'java.exe' - missing entry point in KERNEL.dll - Key: HARMONY-1145 URL: http://issues.apache.org/jira/browse/HARMONY-1145 Project: Harmony Issue Type: Bug Components: VM Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE) Reporter: Radek Terber Attachments: errmsg.gif When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll' -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] junit4.0 fails on harmony due to missing method(s)
Done (r430732) Tim Alexey Varlamov wrote: > Could someone of the fellow comitters kindly apply the HARMONY-1152 > patch, it is needed to use junit4.0: > > java -cp ".:junit-4.0.jar" org.junit.runner.JUnitCore > org.junit.tests.AllTests > JUnit version 4.0 > Exception in thread "main" java.lang.NoSuchMethodError: > java/lang/String.format(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String; > >at > org.junit.runner.Description.createTestDescription(Description.java:39) >at > org.junit.internal.runners.TestClassMethodsRunner.methodDescription(TestClassMethodsRunner.java:83) > >at > org.junit.internal.runners.TestClassMethodsRunner.getDescription(TestClassMethodsRunner.java:51) > >at > org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) > >at > org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) > >at > org.junit.internal.runners.TestClassRunner.getDescription(TestClassRunner.java:57) > >at > org.junit.internal.runners.CompositeRunner.getDescription(CompositeRunner.java:36) > >at org.junit.runner.JUnitCore.run(JUnitCore.java:120) >at org.junit.runner.JUnitCore.run(JUnitCore.java:10) >at org.junit.runner.JUnitCore.run(JUnitCore.java:91) >at org.junit.runner.JUnitCore.runMain(JUnitCore.java:75) >at org.junit.runner.JUnitCore.main(JUnitCore.java:42) > > -- > Alexey > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] platform support ([HARMONY-1145] Cannot run 'java.exe' - missing entry point in KERNEL.dll)
Just FYI if you haven't seen it, seems yet another win2k user was complaining on this. Radek Terber (JIRA) wrote: Cannot run 'java.exe' - missing entry point in KERNEL.dll - Key: HARMONY-1145 URL: http://issues.apache.org/jira/browse/HARMONY-1145 Project: Harmony Issue Type: Bug Components: VM Environment: Windows 2000 SP4, Harmony snapshot 2006-08-04 (both HDK and JRE) Reporter: Radek Terber Attachments: errmsg.gif When try start JRE using 'java.exe', windows display message (is attached to this bug), which means: 'Entry point of procedure AddVectorExceptionHandler not found in dynamic link libryry KERNEL32.dll' -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]Method to terminate VM.
Jimmy, Jing Lv wrote: > Leo Li wrote: >> Hi, all >> During the implementaion of instrument, I encounter the choice about >> how to terminate the VM when some abnormal event occurs, for example, the >> expected jar file does not exist or the implementation class of >> Instrumentation cannot be found. The most simple and direct way is >> just to >> call exit(), and then the whole process will terminate. Hence OS will >> treat >> with all the release of resources. However, I propose to use >> FatalError of >> JNI instead, which notifies the VM to suicide, because it gives right >> to the >> implementation of VM to take charge of its own funeral affairs, which >> might >> include, for example, logging the cause of its crash. >>Any suggestion from VM guys? >>Thanks :) >> > > Hi, > > I agree that use VM FatalError is better than system exit(). If no > objections, I will make code that way. > Agreed, throw an error. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Jimmy, Jing Lv wrote:
> Hi,
>
> As discussed in the former thread, I find that a JNI of DRLVM
> (GetByteArrayRegion) differs from RI in passing parameter
> (byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
> throws an ArrayIndexOutOfBoundsException.
> IMHO, it is better to improve here, make it follow RI, as JNI is
> also a part of API, and users may use it. So if no objections, shall I
> or someone raise a JIRA for this?
Go ahead and raise a JIRA Jimmy.
Regards,
Tim
> I don't know if Martin is urgent in using Harmony in Winstone
> servlet engine (Martin, can you read this?), so shall I work around in
> java code before we have conclusion?
>
> Any comments/suggestions from DRLVM guys? Thanks!
>
>
> Jimmy, Jing Lv wrote:
>> Jimmy, Jing Lv wrote:
>>>
>>>
>>> I do some further study and test then, and find the problem was not
>>> so easy.
>>>
>>> Alex and I are correct that "offset <= buffer.length" here is wrong,
>>> but the next "count <= buffer.length - offset" seems has proved its
>>> correctness.
>>>
>>> I have a test[1], try to write(new byte[count],count, 0) to a
>>> SocketOutputStream, the test passes quietly. I do this test on WinXp
>>> Sp2, the latest Harmony workspace, with J9 VM5.
>>>
>>> I believe the ArrayIndexOutOfBoundsException is throw out when it try
>>> to get byte array in the native (GetByteArrayRegion), which is a JNI
>>> method. I guess there may be some difference between VMs.
>>>
>>> Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
>>> run the test below on DRLVM for me? Thanks!
>>>
>>> [1]
>>> public void test_socketOutputStream() throws Exception {
>>> ServerSocket ss = new ServerSocket(0);
>>> Socket sock = new Socket();
>>> sock.connect(new InetSocketAddress
>>>(InetAddress.getLocalHost(),ss.getLocalPort()));
>>> ss.accept();
>>> OutputStream os = sock.getOutputStream();
>>> os.write(new byte[0], 0, 0); // passes here
>>> os.write(new byte[512], 512, 0); // passes here
>>> }
>>>
>>
>> Hi,
>>
>> At last I have test[1] JNI method(GetByteArrayRegion) of RI
>> (before dinner, very hungry... :) )
>> The result is that, RI return successfully if the given offset
>> equals length of the byte array, and the given count is zero.
>>
>> Thus IMHO it is better to improve DRLVM to follow RI, as JNI
>> methods are also API methods, users may use it.
>>
>> Shall we raise a JIRA for DRLVM? Any comments/suggestions from
>> DRLVM guys? Thanks!
>>
>> Time for dinner! :D
>>
>> [1]
>> test.java
>> --
>> class test
>> {
>> static{
>> System.loadLibrary("testjni");
>> }
>>private native void testjni(byte[] bs);
>> public void usejni(){
>> testjni(new byte[512]);
>> }
>> public static void main(String args[]){
>> new test().usejni();
>> }
>> }
>> ---
>> test.h
>> ---
>> /* DO NOT EDIT THIS FILE - it is machine generated */
>> #include
>> /* Header for class test */
>>
>> #ifndef _Included_test
>> #define _Included_test
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>> /*
>> * Class: test
>> * Method:testjni
>> * Signature: ([B)V
>> */
>> JNIEXPORT void JNICALL Java_test_testjni
>> (JNIEnv *, jobject, jbyteArray);
>>
>> #ifdef __cplusplus
>> }
>> #endif
>> #endif
>> --
>> test.c
>> --
>> #include "test.h"
>> JNIEXPORT void JNICALL Java_test_testjni
>> (JNIEnv * env, jobject obj,jbyteArray array){
>> jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
>> (*env)->GetByteArrayRegion(env,array,512, 0, buf);
>> }
>>
>> (magic number 512 can be any integer, including zero)
>>
>>
>
>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding new files to SVN and subsequently trying to update
Hi, I did not say that it solves all problems, but at least you do not need to do "svn add" each time you add a new file and want to create a patch. Regards, 2006/8/10, Oliver Deakin <[EMAIL PROTECTED]>: I use TortoiseSVN also - I just tested it out by creating a dummy modules\tools\src\main\java\org\apache\harmony\tools\keytool\KeyCertGenerator.java file and trying to update to pick up Mikhails latest changes (which add this file to the repository). Unfortunately TortoiseSVN gives me an error stating "object of the same name already exists". If I delete the file and then try to update, I get another error stating "object of the same name is already scheduled for addition", so it looks like I still have to revert before the update, even with TortoiseSVN. Regards, Oliver Alexei Zakharov wrote: > I use graphical TortoiseSVN client and do not remember much pain with > file addition. It seems TortoiseSVN does some part of the stupid job > by itself. I believe there should be something like it on *NIX too. > > Regards, > > 2006/8/10, Oliver Deakin <[EMAIL PROTECTED]>: >> Alex Blewitt wrote: >> > Yeah ... the problem is that unless you do an 'svn add', it doesn't >> > show up when you have an 'svn patch' or similar (see other swearing, >> > ranting etc. about missing files). So, I've got to add, patch, submit, >> > wait, hack/revert, diff each new file I add ... >> >> Yeah, if you want the file to appear in the patch, then you've got to >> add it. >> Then once you do that you can't update, ugh! I guess you could not do >> the svn add and just attach the files to the JIRA along with the patch >> and describe where they should go, but this takes more effort on the >> part of the committer to put them in the right place and is open to >> mistakes when writing down the path locations of the files (which can >> be pretty long in Harmony!). >> >> > >> > The big problem (for me) is that it effectively means once I've added >> > a new file, I really can't do any new work on it until it's been >> > added, since otherwise any changes I make between filing the patch and >> > having a clean 'svn up' (which I have just got to -- hooray!) are >> > almost certain to be lost in the process. In turn, it means that >> > there's much less of a benefit to me submitting code in smaller >> > chunks, and I might as well just sit on it until I've developed a huge >> > wodge of changes and send them in one go. >> >> If you are following the add, create patch, revert, delete, update, diff >> cycle, then >> at least you can transfer new changes to the svn versioned file during >> the diff stage, so you should be able to continue working on the >> newly added >> file (even if it is a hassle every time you have to update). >> I would be great if svn would recognise that the added file in the >> repo was >> the same as the one added on your disk and attempt to merge them. >> >> There must be someone out there who knows a better way to do this? >> >> Regards, >> Oliver >> >> > >> > Mind you, it's not like we're working against a deadline here, and I'm >> > happy taking a few days off from thinking about it ... but I'll plan >> > where my breaks are better in terms of functionalitiy in the future. >> > >> > (Any SVN developers on this list want to help figure out how to make >> > this better?) >> > >> > Alex. >> > >> > On 10/08/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: >> >> Just sent my other mail before seeing this one. >> >> Rather than manually editing the entries file you can, as I suggest >> >> in the >> >> other mail, still revert the original file name after you have moved >> >> it to >> >> a new file. >> >> >> >> So you could: >> >> - move the file to a new name AddedFile.java.bak >> >> - svn revert AddedFile.java (this should still work even tho the >> file >> >> is no longer there) >> >> - svn up >> >> - compare AddedFile.java and AddedFile.java.bak >> >> - swear etc. >> >> >> >> Hope this helps, >> >> Oliver >> >> >> >> >> >> Alex Blewitt wrote: >> >> > OK, so for anyone else reading this thread (or googling for >> 'object of >> >> > the same name already exists'): >> >> > >> >> > 1) If it's a case insensitive filing system (e.g. Windows) then see >> >> > the Subversion FAQ: http://subversion.tigris.org/faq.html >> >> > 2) If it's a case senstive filing system, and the case is right, >> and >> >> > you're adding a new file to an open-source project and someone's >> >> > already committed that and you're trying to update to pretty >> much the >> >> > same file: >> >> > >> >> > 2a) Move the old file to a new name (e.g. mv AddedFile.java >> >> > AddedFile.java.bak or rename AddedFile.java AddedFile.java.bak) >> >> > 2b) Go into the .svn directory, and open up the file 'entries' >> >> > 2c) Where there is an entry like >> >> > > >> > name="AddedFile.java" >> >> > kind="file" >> >> > schedule="add" >> >> > revision="0"/> >> >> > then delete it from the entries file. It may well be marked as >> >> > read-only, so
RE: [general] platform support
Rana, SetUnhandledExceptionFilter [1] is documented function which is available since Windows 95. It is part of the Structured Exception Handling. Windows XP introduced the Vectored Exception Handling which is an extension of SEH according to MSDN. Using this function and therefore SEH (but not VEH) mechanism requires you to guard each call with __try/__except as Gregory and Oleg pointed out. I'm not proficient in this kind of rather low-level Windows API though, so I might be wrong. Regards, Alexey. [1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/b ase/setunhandledexceptionfilter.asp -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Rana Dasgupta [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 10, 2006 9:51 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [general] platform support > >Hi Mikhail, >As far as I know, SetUnhandledExceptionFilter was introduced as a >backdoor method in in Win2K SP4 to get around the problem that the SEH >handlers are limited to the frame and not process wide. It does handle >problems like NPE and AV, but as you point out, it works by hijacking the >first and last chance debugger handlers. So, unlike VEH which are fully >functional when debugging, these SetUnhandled...filters are not visible >when >debugging. I also believe that they execute in the context of the current >thread, which means that they are not so good to handle stack corruption, >SOE etc. which we are currently using VEH. Since one does not expect them >to >be used on the newer Windows boxes, the .Net framework overwrites them >...which means that any process that loads a Microsoft dll that has any >Microsoft managed code in it ( and many do ), is at a risk that the >SetUnhandled.. may or may not work. > I think that SetUnhandled..was a great(probably only ) solution on the >Win2K boxes, but VEH was put in place to solve some of its limitations. The >bottom line is that one needs to experiment with this on several Windows >boxes before we know how good or bad it is. I myself don't have a lot of >experience with it. > >Thanks, >Rana > > >On 8/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote: >> >> >**Using "SetUnhandledExceptionFilter" API call we can handle hardware >NPE >> >for Win2k too. >> >The only problem is debbuging of applications with exception filter >> >installed. AFAIK debugger will catch all of these events. >> >> - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: [classlib][pack200] Status update
Done in 430723 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: Only one problem I've found so far (possibly because it was in an earlier patch but not subsequent ones) -- the src/test/java/org/apache/harmony/archive/tests/AllTests.java doesn't have a suite.addTest(org.apache.harmony.archive.tests.internal.pack200.AllTests.suite()); in it. Can you add that, or do you want me to send a patch? (Mind you, with my record of submitting patches, I'm not sure that's such a good idea ;-) Alex. On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > Finally it's in! :) > > 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > > Don't you just hate it when that happens? > > > > :-) > > > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > I've found this file in > > > http://issues.apache.org/jira/browse/HARMONY-634 > > > > > > Tim decisded not to commit it as it was not used at the moment > > > > > > I'll check if it solves the problem > > > > > > Thanks, > > > Mikhail > > > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > The test still fails. > > > > > > > > I have not found any file named JustResources* in SVN. > > > > > > > > The only pack file I've found is HelloWorld.pack > > > > > > > > Do you remember who has added a JustResources there? Was it a JIRA issue > > > > reported by you? > > > > > > > > Thanks, > > > > Mikhail > > > > > > > > 2006/8/10, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > Bizzare. I moved it, but it didn't get added. Or at least, I think so. > > > > > I did discover why the file wasn't included though at my end ... it > > > > > wasn't part of the change set, so wasn't included in the patch. > > > > > > > > > > I've re-generated the patch with it in this time and attached to > > > > > Harmony-1019 ... is that any better? > > > > > > > > > > Alex. > > > > > > > > > > On 10/08/06, Alex Blewitt <[EMAIL PROTECTED]> wrote: > > > > > > I believe that the JustResources.pack file was moved to a different > > > > > > location, and so the test was updated to reflect that new location. I > > > > > > saw the same problem myself ... can you confirm that there is a file > > > > > > in the src/test/resources/o/a/h/a/t/i/p/JustResources.pack location? I > > > > > > think that's where the segment ended up. I didn't actually move the > > > > > > file ... someone else did IIRC. > > > > > > > > > > > > Alex. > > > > > > > > > > > > > > > > > > On 10/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > One more problem caused by the patch: > > > > > > > > > > > > > > java.lang.NullPointerException at > > > > > > > org.apache.harmony.archive.internal.pack200.Segment.parseSegmentHeader(Segment.java:856) > > > > > > > at org.apache.harmony.archive.internal.pack200.Segment.parseSegment(Segment.java:825) > > > > > > > at org.apache.harmony.archive.internal.pack200.Segment.parse(Segment.java:83) > > > > > > > at org.apache.harmony.archive.tests.internal.pack200.SegmentTest.testJustResources(SegmentTest.java:41) > > > > > > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > > > > > > > > > > > > > Thanks, > > > > > > > Mikhail > > > > > > > > > > > > > > 2006/8/10, Mikhail Loenko <[EMAIL PROTECTED]>: > > > > > > > > PopulationCodecTest is missing, but there are other new files in the patch. > > > > > > > > > > > > > > > > You can see all of them if open the patch with a text editor and seek for > > > > > > > > "(revision 0)" substring > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Mikhail > > > > > > > > > > > > > > > > 2006/8/9, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > > > > Weird. I don't know what happened. I've attached PopulationCodec (a > > > > > > > > > new file) separately to the bug report. There's also BHSDCodec, which > > > > > > > > > is new in the patch, as well as PopulationCodecTest. Are they there > > > > > > > > > too? > > > > > > > > > > > > > > > > > > Alex. > > > > > > > > > > > > > > > > > > On 08/08/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi Alex > > > > > > > > > > > > > > > > > > > > Thanks for the patch! > > > > > > > > > > > > > > > > > > > > I have a problem with integration: this classes > > > > > > > > > > org.apache.harmony.archive.internal.pack200.CodecEncoding > > > > > > > > > > refers to the PopulationCodec class that seems to be missing > > > > > > > > > > > > > > > > > > > > I'm trying to apply 'patch' [1]. Am I doing anything wrong? > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Mikhail > > > > > > > > > > > > > > > > > > > > [1] http://issues.apache.org/jira/secure/attachment/12338321/patch > > > > > > > > > > > > > > > > > > > > 2006/8/8, Alex Blewitt <[EMAIL PROTECTED]>: > > > > > > > > > > > I've been getting further towards the Pack200 implementation with > > > > > > > > > > > finishing off the codecs that are used to decode values from the file. > > > > > > > > > > > Although most of the default codecs were in place, the pack200 spec
Re: RE: [classlib][suncompat] created
I think the @deprecated is a good idea, but I strongly believe that we should *not* have this as a default. There's an easy workaround for the subset of applications that need it (e.g. enable it in the .properties file) whilst still preventing new code from being able to reference it. A simple FAQ should be enough to help people do this. Mind you, I seem to be in the minority on this view on this list :-) Alex. On 11/08/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: I agree, let's just enable it by default. I would suggest that we tag all of these classes as @Deprecated with a nice message saying you really shouldn't be using this. -Nathan > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 11:13 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib][suncompat] created > > Oh - definitely only add as needed, and yes, we need to have good > documentation to assist users. > > And I'm very +1 about including this by default for now. See other > threads as for why. > > geir > > Alex Blewitt wrote: > > Sounds like a FAQ in the making :-) > > > > On 10/08/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > >> Alex Blewitt wrote: > >> > OK. What's the plan with regards to adding items in here e.g. Base64 > >> > or tools like JavaC? Or do we just add them organically as we find > >> > problems? > >> > >> Let's try and keep this JAR as small as possible, only adding types > >> after a debate on the list concludes that it is a 'necessity'. > >> > >> Regards, > >> Tim > >> > >> -- > >> > >> Tim Ellison ([EMAIL PROTECTED]) > >> IBM Java technology centre, UK. > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
