Re: [Jscheme-user] Problems loading contributed scheme code+install stuff

[Timothy J. H. <tim...@ma...>]

On Feb 23, 2005, at 2:30 PM, Joseph Toman wrote:

> Timothy J Hickey wrote:
>> Hi Joseph,
>>   I'm away from work for a week (with a Mac but no Linux, and hence 
>> no jdk1.5...)
>> I'll look into it when I return, but I think the problem is in the 
>> implementation of
>> quasistrings. Tatu Tarvainen diagnosed the problem in an 
>> jscheme-devel email
>> last October 22 (2004):
>>> Some Java-calls don't seem to work under JDK 1.5.0.
>>> Using quasi-strings fails, because the StringBuffer append method 
>>> fails.
>>>
>>> This happens with the latest jscheme jar and the CVS version.
>>> I think the reflective access to the append method fails because in 
>>> Java
>>> 5 the java.lang.StringBuffer class inherits from a new
>>> java.lang.AbstractStringBuilder class which is not public and also
>>> provides the append method.
>
> ??? Not as far as I can see, looking at the 1.5 JDK javadoc. The only
> change I see is the addition of a StringBuilder class which is a drop 
> in replacement for StringBuffer, and which they recommend using if the 
> original StringBuffer is only used in a single thread.
You wouldn't see the private class in the javadoc.

If you can get jscheme to work (without elf), you can find the private 
class using ...
     (define sb (StringBuffer.))
     (.getClass sb)
and it should return java.lang.AbstactStringBuilder

If this throws an exception, you might need to use the # to indicate
javadot that accesses private methods ...
     (.getClass# sb)

Does this return the AbstractStringBuilder class?
(I'll check it myself when I return from vacation on Monday....)

>
>>>
>> Since I work mainly on the Mac I haven't been using jdk1.5. I'll 
>> install it on my
>> Linux box when I return and see how it works. The fix is probably to 
>> modify
>> the code implementing quasistrings by replacing all  (.append sb ...) 
>> calls with
>> (.StringBuffer.append sb ....)
>
> Is there a difference between .StringBuffer.append and .append ?
Yes,
    (.StringBuffer.append sb "abc")
looks up the append instance method of the StringBuffer class which has 
one String argument.
It then applies it to the sb object with the string argument "abc"

    (.append sb "abc")
calls a reflection method to get the class of the sb object and then 
uses that class
to find an append instance method with one string argument. It may have 
to pass to the
ancestor classes to find the appropriate method.

The main difference is that the javadot which includes the classname
    (.StringBuffer.append sb "abc")
does not have to dynamically find the class of the sb object. It could 
be that
sb is a private class which extends the StringBuffer class.
This notation is especially useful when writing applets where there are 
many
restrictions on reflection.

Note that you can also include the full classname
   (.java.lang.StringBuffer.append sb "abc")
The initial dot indicates that it is an instance method.


>
>
>> On Feb 22, 2005, at 6:20 PM, Joseph Toman wrote:
>>> A) These are in reverse order, but the transcript below is so long I 
>>> thought this might get lost. After B) I tried getting the current 
>>> codebase from CVS and building it. I'm sure this marks me as not 
>>> being a true-believer, but wouldn't a Makefile or a build.xml be 
>>> perhaps less exciting, but ultimately more useful ? Suffice to say I 
>>> couldn't get it
>>> to build, though I got very close once I abandoned the default 
>>> method and built an Eclipse project for it. build.CompilingLoadlet 
>>> uses internal sun.* classes which apparently didn't make it to JDK 
>>> 1.5,
>> Ahhh. I'll have to look into this also.
>> The pure JScheme approach is nice because it works on all platforms 
>> (except of course when a new version of Java requires
>> breaks it temporarily....) and you don't need to download any 
>> additional tools (cygwin, ant, ...)
>> I'll track down those sun.* dependencies.
>
>
> Well, once you've installed a JDK, javax.servlet.jar and bsf.jar, one 
> little ant.jar isn't that much. I think I'll write a build.xml and
> post it somewhere once I'm done with my current project.
That would be great. If you'ld care to denote it to the JScheme 
project, we can include it in the CVS codebase.

> For production
> systems it's useful to have a vanilla build that integrates with other 
> environments and ant is fairly ubiquitous.
I agree. For those that are using Ant regularly, it would be nice to 
have an ant-friendly build file....

Best wishes,
---Tim Hickey---


>
>
> 						Thanks,
> 							J. Toman
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Jscheme-user mailing list
> Jsc...@li...
> https://lists.sourceforge.net/lists/listinfo/jscheme-user