[gentoo-java] java 5 classpath policy?

[gentoo-java] java 5 classpath policy?

[Vincent Schut]

Hi all,

when using java-config-2 from migration-overlay, it says 'deprecated'
for all classpath related functions. I tried to find some more info on
this, but couldn't find it. Maybe someone here can elaborate a bit more
on how to work with java classpath (system and user) in the new gentoo
java system? E.g. if I want to have some packages in my classpath, how
would I do that using the new system? And how is this working
together/conflicting with the current (old) items in /etc/env.d/ ?

Cheers,
Vincent.
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] java 5 classpath policy?

[Joshua Nichols]

Vincent Schut wrote:
> Hi all,
>
> when using java-config-2 from migration-overlay, it says 'deprecated'
> for all classpath related functions. I tried to find some more info on
> this, but couldn't find it. Maybe someone here can elaborate a bit more
> on how to work with java classpath (system and user) in the new gentoo
> java system? E.g. if I want to have some packages in my classpath, how
> would I do that using the new system? And how is this working
> together/conflicting with the current (old) items in /etc/env.d/ ?
>
> Cheers,
> Vincent.
>   

Setting a user and system wide classpath is deprecated because it can
cause several issues.

For example, say you put the classes from foo-2.0 on your classpath.
Then you emerge something that uses foo-1.0. This would because foo
would be slotted. However, when the build takes place, foo-2.0 could be
on the classpath before foo-1.0. It may have the same classnames and
whatnot, but different API. The differences between the APIs could then
cause the build to fail.

Similarly, this scenario may also occur while running an application.
foo-1.0 might be expected, but foo-2.0 is on the classpath first... so
it may be missing methods, or have different behavior, and so on.


As for what to do instead of setting the classpath, it depends on what
you're trying to do. If you have an application that needs a certain
thing on the classpath, it is best to have a launcher script which sets
the right CLASSPATH. If you're building something that needs a
particular library, you should make the something be explicitly aware of
what it needs. In ant, this could mean having a lib directory with all
the jars (or symlinks to them), then you create a <path> that all your
<javac> and <java>'s use. This would really be dependent on how you're
building your project.

This problem, and workarounds for it, are in the updated user
documentation
(https://svn.gentooexperimental.org/svn/java/migration/docs/java-user.html).

Hope this clarifies,

Josh
-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] java 5 classpath policy?

[Vincent Schut]

Joshua Nichols wrote:

>Vincent Schut wrote:
>  
>
>>Hi all,
>>
>>when using java-config-2 from migration-overlay, it says 'deprecated'
>>for all classpath related functions. I tried to find some more info on
>>this, but couldn't find it. Maybe someone here can elaborate a bit more
>>on how to work with java classpath (system and user) in the new gentoo
>>java system? E.g. if I want to have some packages in my classpath, how
>>would I do that using the new system? And how is this working
>>together/conflicting with the current (old) items in /etc/env.d/ ?
>>
>>Cheers,
>>Vincent.
>>  
>>    
>>
>
>Setting a user and system wide classpath is deprecated because it can
>cause several issues.
>
>For example, say you put the classes from foo-2.0 on your classpath.
>Then you emerge something that uses foo-1.0. This would because foo
>would be slotted. However, when the build takes place, foo-2.0 could be
>on the classpath before foo-1.0. It may have the same classnames and
>whatnot, but different API. The differences between the APIs could then
>cause the build to fail.
>
>Similarly, this scenario may also occur while running an application.
>foo-1.0 might be expected, but foo-2.0 is on the classpath first... so
>it may be missing methods, or have different behavior, and so on.
>
>
>As for what to do instead of setting the classpath, it depends on what
>you're trying to do. If you have an application that needs a certain
>thing on the classpath, it is best to have a launcher script which sets
>the right CLASSPATH. If you're building something that needs a
>particular library, you should make the something be explicitly aware of
>what it needs. In ant, this could mean having a lib directory with all
>the jars (or symlinks to them), then you create a <path> that all your
><javac> and <java>'s use. This would really be dependent on how you're
>building your project.
>
>This problem, and workarounds for it, are in the updated user
>documentation
>(https://svn.gentooexperimental.org/svn/java/migration/docs/java-user.html).
>
>Hope this clarifies,
>  
>
It sure does. Thanks.

Vincent.

>Josh
>  
>

-- 
gentoo-java@gentoo.org mailing list