Smalltalk › Redline Smalltalk

Classloading issue

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Stefan Krecher

Classloading issue

Hi,

i'm still struggling with the class-name/path problem under windows and encounter a StackOverflowException in method loadObject in ProtoObject:

protected ProtoObject loadObject(String name) {

try {

return (ProtoObject) Class.forName(name.replaceAll("/","."), true, classLoader()).newInstance();

} catch (Exception e) {

throw RedlineException.withCause(e);

}

calling of newInstance() causes somehow to recursively execute the loadObject-Method until the StackOverflow is thrown

Does anybody have an idea why this happens? Is this a bug or did i mess up something?

regards,

Stefan

Stefan Krecher

Re: Classloading issue

Sorry, it was another bug i produced by replacing Fileseparators and slashes with ".".

The class-naming thing is very annoying. Internal representation is "st/redline/Object" while Class.forName wants "st.redline.Object"

There are multiple places where full-package-names are constructed - in the original version there where often used Fileseparators ...

Robert Roland

Re: Classloading issue

Hi Stefan,

I saw some classloading issues in Windows yesterday but I apparently didn't get them all fixed. I'm going to attempt a comprehensive fix for classloading issues that works on Mac, Linux and Windows today. I'll reply when I get that patch submitted.

Thanks,

Rob

On Wed, Sep 14, 2011 at 6:14 AM, Stefan Krecher <[hidden email]> wrote:

Sorry, it was another bug i produced by replacing Fileseparators and slashes with ".".
The class-naming thing is very annoying. Internal representation is "st/redline/Object" while Class.forName wants "st.redline.Object"

There are multiple places where full-package-names are constructed - in the original version there where often used Fileseparators ...

Stefan Krecher-2

Re: Classloading issue

Hi Rob,

i think i solved that problem - see my lasst message. I did a pull request with the latest changes, hope this works on all platforms. Maybe you want to test it?

regards,

Stefan

2011/9/14 Rob Roland <[hidden email]>

Hi Stefan,

I saw some classloading issues in Windows yesterday but I apparently didn't get them all fixed. I'm going to attempt a comprehensive fix for classloading issues that works on Mac, Linux and Windows today. I'll reply when I get that patch submitted.

Thanks,

Rob

On Wed, Sep 14, 2011 at 6:14 AM, Stefan Krecher <[hidden email]> wrote:

Sorry, it was another bug i produced by replacing Fileseparators and slashes with ".".
The class-naming thing is very annoying. Internal representation is "st/redline/Object" while Class.forName wants "st.redline.Object"

There are multiple places where full-package-names are constructed - in the original version there where often used Fileseparators ...

--
Dipl.-Wirtsch.-Inf. Stefan Krecher
Neulander Str. 17, 27374 Visselhövede
Tel +49(0)4262 958848
mobil +49(0)172 3608616
http://krecher.com

Robert Roland

Re: Classloading issue

I'll take a look. I would like to abstract all of that away into simple, static helper class as opposed to littering the code with random .replaceAll() statements. :)

Thanks,

- Rob

On Wed, Sep 14, 2011 at 7:59 AM, Stefan Krecher <[hidden email]> wrote:

Hi Rob,
i think i solved that problem - see my lasst message. I did a pull request with the latest changes, hope this works on all platforms. Maybe you want to test it?
regards,
Stefan

2011/9/14 Rob Roland <[hidden email]>
Hi Stefan,

I saw some classloading issues in Windows yesterday but I apparently didn't get them all fixed. I'm going to attempt a comprehensive fix for classloading issues that works on Mac, Linux and Windows today. I'll reply when I get that patch submitted.

Thanks,

Rob

On Wed, Sep 14, 2011 at 6:14 AM, Stefan Krecher <[hidden email]> wrote:

Sorry, it was another bug i produced by replacing Fileseparators and slashes with ".".
The class-naming thing is very annoying. Internal representation is "st/redline/Object" while Class.forName wants "st.redline.Object"

There are multiple places where full-package-names are constructed - in the original version there where often used Fileseparators ...

--
Dipl.-Wirtsch.-Inf. Stefan Krecher
Neulander Str. 17, 27374 Visselhövede
Tel <a href="tel:%2B49%280%294262%20958848" value="+494262958848" target="_blank">+49(0)4262 958848
mobil <a href="tel:%2B49%280%29172%203608616" value="+491723608616" target="_blank">+49(0)172 3608616
http://krecher.com

Stefan Krecher

Re: Classloading issue

You're absolutly right the code should be refactored - if it is working now on all platforms i could do that.

regards,

Stefan

Robert Roland

Re: Classloading issue

There is a workaround - on Windows, invoke Stic as the following:

cd target\redline-deploy
stic.bat -r rt -s examples st\redline\Subclass

Use \ instead of . as a separator on the command line to stic. We'll have to use this as a workaround until a more comprehensive solution is complete. Doing a replaceAll in Stic.java isn't the answer, as that makes it stop working on Linux and Mac platforms.

That should help any Windows user run the code, as it is in master, today.

On Wed, Sep 14, 2011 at 8:15 AM, Stefan Krecher <[hidden email]> wrote:

You're absolutly right the code should be refactored - if it is working now on all platforms i could do that.
regards,
Stefan

Stefan Krecher-2

Re: Classloading issue

i'm not doing any replacements in Stic.java - the problems go deeper. In master classnames are built with the path-sep - that is causing errors (and regards all classes, not only the ones passed to the commandline)

--
sent from my android-phone

Am 14.09.2011 17:59 schrieb "Rob Roland" <[hidden email]>:
> There is a workaround - on Windows, invoke Stic as the following:
>
> cd target\redline-deploy
> stic.bat -r rt -s examples st\redline\Subclass
>
> Use \ instead of . as a separator on the command line to stic. We'll have
> to use this as a workaround until a more comprehensive solution is
> complete. Doing a replaceAll in Stic.java isn't the answer, as that makes
> it stop working on Linux and Mac platforms.
>
> That should help any Windows user run the code, as it is in master, today.
>
> On Wed, Sep 14, 2011 at 8:15 AM, Stefan Krecher <
> [hidden email]> wrote:
>
>> You're absolutly right the code should be refactored - if it is working now
>> on all platforms i could do that.
>> regards,
>> Stefan
>>

James Ladd

Re: Classloading issue

In reply to this post by Robert Roland

On the command line and when importing classes we need to use the "." notation.
Eg: ./stic -s examples st.redline.Foo

Internally to the JVM the fully qualified path is st/redline/Foo regardless of platform.

There is code that forms fully qualified paths from '.' notations and the problem arises because
in one instance it needs to be uses as a file system path and therefore replaced with a File.separator
and in another instance it needs to be replaced with '/' because the name is being used as the
internal JVM name.

The need to replace '.' with '/' should (from memory) be required only in the ClassByteCodeWriter.

Please work from the code in HEAD to get this fixed.

On Thu, Sep 15, 2011 at 1:59 AM, Rob Roland <[hidden email]> wrote:

There is a workaround - on Windows, invoke Stic as the following:

cd target\redline-deploy
stic.bat -r rt -s examples st\redline\Subclass

Use \ instead of . as a separator on the command line to stic. We'll have to use this as a workaround until a more comprehensive solution is complete. Doing a replaceAll in Stic.java isn't the answer, as that makes it stop working on Linux and Mac platforms.

That should help any Windows user run the code, as it is in master, today.

On Wed, Sep 14, 2011 at 8:15 AM, Stefan Krecher <[hidden email]> wrote:

You're absolutly right the code should be refactored - if it is working now on all platforms i could do that.
regards,
Stefan