Implicits masking use of Java 1.6 specifics (which then fail at runtime on 1.5)

Were any other releases of Scala were compiled against Java 1.6?

2.7.7 would be useless for LinkedIn if it's compiled against 1.6.

--j

On Wed, Sep 23, 2009 at 3:59 PM, Miles Sabin <miles@milessabin.com> wrote:

See the #2380 and in particular my comment #6 here,

 https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6

There seem to be several long term solutions, none of them entirely
satisfactory,

* Provide JDK-version specific builds.
* Build releases against the minimum required JDK version.
* Special-case methods like String.isEmpty (maybe via an annotation)
and compile in a backwards compatible way.
* Avoid uses of methods like String.isEmpty altogether.

I've gone for the last of these as the fix for #2380 for 2.7.7 because
we're out of time for the others. But it's really not at all
satisfactory because it's difficult to statically check that there are
no uses of such 1.6 methods.

Suggestions welcome ...

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On Thu, Sep 24, 2009 at 1:45 AM, Jorge Ortiz wrote:
> Were any other releases of Scala were compiled against Java 1.6?
>
> 2.7.7 would be useless for LinkedIn if it's compiled against 1.6.

It's been that way for a while. It's targeted to 1.5, however.

Cheers,

Miles

For 2.8 there will most likely be two releases (1.5 and 1.6) because actors can profit
from 1.6, and the Array.newInstance interface is different.

However, the 1.5 release might be only a "plain" scala build without sbaz or eclipse,
only compiler and library, similar to what we did before with 1.4. People running a
server on 1.5 can take scala-library.jar from there, but the recommended version
would be 1.6.


Lukas




On Thu, Sep 24, 2009 at 00:59, Miles Sabin <miles@milessabin.com> wrote:

See the #2380 and in particular my comment #6 here,

 https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6

There seem to be several long term solutions, none of them entirely
satisfactory,

* Provide JDK-version specific builds.
* Build releases against the minimum required JDK version.
* Special-case methods like String.isEmpty (maybe via an annotation)
and compile in a backwards compatible way.
* Avoid uses of methods like String.isEmpty altogether.

I've gone for the last of these as the fix for #2380 for 2.7.7 because
we're out of time for the others. But it's really not at all
satisfactory because it's difficult to statically check that there are
no uses of such 1.6 methods.

Suggestions welcome ...

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

On 24 Sep 2009, at 02:15, Miles Sabin wrote:

> On Thu, Sep 24, 2009 at 1:45 AM, Jorge Ortiz
> wrote:
>> Were any other releases of Scala were compiled against Java 1.6?
>>
>> 2.7.7 would be useless for LinkedIn if it's compiled against 1.6.
>
> It's been that way for a while. It's targeted to 1.5, however.

In my experience, the only way to know if you're using 1.5 subset is
to compile/test against 1.5. One difference is of course whether new
methods exist or not (which Miles was discussing yesterday on Twitter)
but there's also the fact that methods with same signatures can take a
different range of values (e.g. an int method can now take negative
values wheras in the previous version it could only take positive).
>

FWIW in Eclipse, each bundle has a minimal version of Java which is
used to configure what libraries to compile against. We could
(eventually) do something similar for Scala which could allow one
module being compiled against 1.5 whilst allowing another module to be
compiled against 1.6.

Whilst 1.5 is EOL next month, practically speaking, large companies
may continue to use it for a while. It might make sense for there to
be a compile/test against 1.5, even if those bits aren't separately
distributed. That will give the greatest chance of finding API leakage
sooner and should be relatively simple to set up.

Alex

On Thu, Sep 24, 2009 at 8:05 AM, Alex Blewitt wrote:
> In my experience, the only way to know if you're using 1.5 subset is to
> compile/test against 1.5.

The issue here is that compiling against 1.5 doesn't help if the
method is provided by an implicit if it's missing.

Cheers,

Miles

Let us all just keep in mind that industry does not follow versions that easily. Benefitting from 1.6 is great and this is what I will have in my personal laptop (and try to push to customers) but we need to make sure the 1.5 world gets the same treatment as the 1.6 world. At least for a year, I would propose.
On Sep 24, 2009, at 09:56, Lukas Rytz wrote:

For 2.8 there will most likely be two releases (1.5 and 1.6) because actors can profit
from 1.6, and the Array.newInstance interface is different.

However, the 1.5 release might be only a "plain" scala build without sbaz or eclipse,
only compiler and library, similar to what we did before with 1.4. People running a
server on 1.5 can take scala-library.jar from there, but the recommended version
would be 1.6.


Lukas




On Thu, Sep 24, 2009 at 00:59, Miles Sabin <miles@milessabin.com> wrote:

See the #2380 and in particular my comment #6 here,

 https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6

There seem to be several long term solutions, none of them entirely
satisfactory,

* Provide JDK-version specific builds.
* Build releases against the minimum required JDK version.
* Special-case methods like String.isEmpty (maybe via an annotation)
and compile in a backwards compatible way.
* Avoid uses of methods like String.isEmpty altogether.

I've gone for the last of these as the fix for #2380 for 2.7.7 because
we're out of time for the others. But it's really not at all
satisfactory because it's difficult to statically check that there are
no uses of such 1.6 methods.

Suggestions welcome ...

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

-- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

For what it's worth, we will continue to target 1.5 at work, because
1.6 does not exist on 32-bit Macs. It's possible that this only
matters because my boss's machine is one of those, but it's equally
possible that some of our customers use 32-bit Macs.

I'd suggest at least making sure that EPFL's Hudson builds and tests
on 1.5. Would this require two versions of starr?

2009/9/24 Christos KK Loverdos :
> Let us all just keep in mind that industry does not follow versions that
> easily. Benefitting from 1.6 is great and this is what I will have in my
> personal laptop (and try to push to customers) but we need to make sure the
> 1.5 world gets the same treatment as the 1.6 world. At least for a year, I
> would propose.
> On Sep 24, 2009, at 09:56, Lukas Rytz wrote:
>
> For 2.8 there will most likely be two releases (1.5 and 1.6) because actors
> can profit
> from 1.6, and the Array.newInstance interface is different.
>
> However, the 1.5 release might be only a "plain" scala build without sbaz or
> eclipse,
> only compiler and library, similar to what we did before with 1.4. People
> running a
> server on 1.5 can take scala-library.jar from there, but the recommended
> version
> would be 1.6.
>
>
> Lukas
>
>
>
>
> On Thu, Sep 24, 2009 at 00:59, Miles Sabin wrote:
>>
>> See the #2380 and in particular my comment #6 here,
>>
>>  https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6
>>
>> There seem to be several long term solutions, none of them entirely
>> satisfactory,
>>
>> * Provide JDK-version specific builds.
>> * Build releases against the minimum required JDK version.
>> * Special-case methods like String.isEmpty (maybe via an annotation)
>> and compile in a backwards compatible way.
>> * Avoid uses of methods like String.isEmpty altogether.
>>
>> I've gone for the last of these as the fix for #2380 for 2.7.7 because
>> we're out of time for the others. But it's really not at all
>> satisfactory because it's difficult to statically check that there are
>> no uses of such 1.6 methods.
>>
>> Suggestions welcome ...
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 (0)7813 944 528
>> skype:  milessabin
>> http://www.chuusai.com/
>> http://twitter.com/milessabin
>
>
> --
>    __~O
>   -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>
>
>
>
>
>

On Thu, Sep 24, 2009 at 9:55 AM, Christos KK Loverdos
wrote:
> Let us all just keep in mind that industry does not follow versions that
> easily. Benefitting from 1.6 is great and this is what I will have in my
> personal laptop (and try to push to customers) but we need to make sure the
> 1.5 world gets the same treatment as the 1.6 world. At least for a year, I
> would propose.

Bear in mind that Sun isn't offering a straightforward download for
1.5 any more (you have to register first) and warn prominently when
you do eventually get to the download link that 1.5 (for non-paying
customers) will be EOL'd on the Oct 30th 2009.

Should our commitment to 1.5 be greater than Sun's?

Cheers,

Miles

On Thu, Sep 24, 2009 at 11:00, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

For what it's worth, we will continue to target 1.5 at work, because
1.6 does not exist on 32-bit Macs.  It's possible that this only
matters because my boss's machine is one of those, but it's equally
possible that some of our customers use 32-bit Macs.

I'd suggest at least making sure that EPFL's Hudson builds and tests
on 1.5.  Would this require two versions of starr?

Hudson used to run with 1.5 until two days ago. We changed it because the
build would fail due to the Array.newInstance interface. However, we still test
1.5 https://scala-webapps.epfl.ch/hudson/job/scala-nightly-auxjvm/

Cheers
 

2009/9/24 Christos KK Loverdos <loverdos@gmail.com>:
> Let us all just keep in mind that industry does not follow versions that
> easily. Benefitting from 1.6 is great and this is what I will have in my
> personal laptop (and try to push to customers) but we need to make sure the
> 1.5 world gets the same treatment as the 1.6 world. At least for a year, I
> would propose.
> On Sep 24, 2009, at 09:56, Lukas Rytz wrote:
>
> For 2.8 there will most likely be two releases (1.5 and 1.6) because actors
> can profit
> from 1.6, and the Array.newInstance interface is different.
>
> However, the 1.5 release might be only a "plain" scala build without sbaz or
> eclipse,
> only compiler and library, similar to what we did before with 1.4. People
> running a
> server on 1.5 can take scala-library.jar from there, but the recommended
> version
> would be 1.6.
>
>
> Lukas
>
>
>
>
> On Thu, Sep 24, 2009 at 00:59, Miles Sabin <miles@milessabin.com> wrote:
>>
>> See the #2380 and in particular my comment #6 here,
>>
>>  https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6
>>
>> There seem to be several long term solutions, none of them entirely
>> satisfactory,
>>
>> * Provide JDK-version specific builds.
>> * Build releases against the minimum required JDK version.
>> * Special-case methods like String.isEmpty (maybe via an annotation)
>> and compile in a backwards compatible way.
>> * Avoid uses of methods like String.isEmpty altogether.
>>
>> I've gone for the last of these as the fix for #2380 for 2.7.7 because
>> we're out of time for the others. But it's really not at all
>> satisfactory because it's difficult to statically check that there are
>> no uses of such 1.6 methods.
>>
>> Suggestions welcome ...
>>
>> Cheers,
>>
>>
>> Miles
>>
>> --
>> Miles Sabin
>> tel: +44 (0)7813 944 528
>> skype:  milessabin
>> http://www.chuusai.com/
>> http://twitter.com/milessabin
>
>
> --
>    __~O
>   -\ <,       Christos KK Loverdos
> (*)/ (*)      http://ckkloverdos.com
>
>
>
>
>
>



--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com

There is still a registration-free link for J2SE 5.0 bundled with
NetBeans. However this is not about our community's commitment to 5.0,
it's about our commitment to users. If Scala requires Java 6 then
nobody building products in Scala will be able to support users
running Java 5, whether they are paying customers or not.

Don't expect 5.0 to go away in the short term. For many corporate
users getting off 5.0 will require a large investment with very little
gain; in this economy it's far better to pay a bit of cash to Sun for
continued support.

Neil

On Thu, Sep 24, 2009 at 10:10 AM, Miles Sabin wrote:
> On Thu, Sep 24, 2009 at 9:55 AM, Christos KK Loverdos
> wrote:
>> Let us all just keep in mind that industry does not follow versions that
>> easily. Benefitting from 1.6 is great and this is what I will have in my
>> personal laptop (and try to push to customers) but we need to make sure the
>> 1.5 world gets the same treatment as the 1.6 world. At least for a year, I
>> would propose.
>
> Bear in mind that Sun isn't offering a straightforward download for
> 1.5 any more (you have to register first) and warn prominently when
> you do eventually get to the download link that 1.5 (for non-paying
> customers) will be EOL'd on the Oct 30th 2009.
>
> Should our commitment to 1.5 be greater than Sun's?
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype:  milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin
>

On Thu, Sep 24, 2009 at 10:31 AM, Neil Bartlett wrote:
> Don't expect 5.0 to go away in the short term. For many corporate
> users getting off 5.0 will require a large investment with very little
> gain; in this economy it's far better to pay a bit of cash to Sun for
> continued support.

Which is fine, but who's paying a little bit of cash to EPFL? (or me
for that matter seeing as I'm expected to support the IDE on 1.5).

Cheers,

Miles

Neil Bartlett wrote:
> Don't expect 5.0 to go away in the short term. For many corporate
> users getting off 5.0 will require a large investment with very little
> gain; in this economy it's far better to pay a bit of cash to Sun for
> continued support.

Each time the argument that company will prefer to continue to use old
version of Java, because new one bring them too few things, I can't stop
wondering if these companies are likely to be early users of new
technologies such as Scala. I was wondering the same thing about the
argument against reified generics in java 1.5...

Well, I tend to thing that companies that are not willing to update to
last Java version for new softwares are not likely to try to use Scala
based software.
But of course, I can understand that perhaps only the possibility of
such a case is sufficient too make the work be done.

All in all, it's better to have too really well working and tested
distribution of Scala, one for 1.5 and one for 1.6. I mean, if time can
be spend on that, I won't complained to be able to choose :)

I look forward to providing our customers/my boss with the build of
Java 6 for 32-bit Macs that you will supply in order to make your
assertion true.

Also, there are departments within *Sun* who will not use anything above Java 5.

2009/9/24 Francois :
> Neil Bartlett wrote:
>>
>> Don't expect 5.0 to go away in the short term. For many corporate
>> users getting off 5.0 will require a large investment with very little
>> gain; in this economy it's far better to pay a bit of cash to Sun for
>> continued support.
>
> Each time the argument that company will prefer to continue to use old
> version of Java, because new one bring them too few things, I can't stop
> wondering if these companies are likely to be early users of new
> technologies such as Scala. I was wondering the same thing about the
> argument against reified generics in java 1.5...
>
> Well, I tend to thing that companies that are not willing to update to last
> Java version for new softwares are not likely to try to use Scala based
> software.
> But of course, I can understand that perhaps only the possibility of such a
> case is sufficient too make the work be done.
>
> All in all, it's better to have too really well working and tested
> distribution of Scala, one for 1.5 and one for 1.6. I mean, if time can be
> spend on that, I won't complained to be able to choose :)
>

On Thu, Sep 24, 2009 at 10:43 AM, Francois wrote:
> Each time the argument that company will prefer to continue to use old
> version of Java, because new one bring them too few things, I can't stop
> wondering if these companies are likely to be early users of new
> technologies such as Scala. I was wondering the same thing about the
> argument against reified generics in java 1.5...

Don't make the mistake of treating large companies as monoliths. IT
departments of course dislike Java 6, Scala and other new-fangled
nonsense, whereas developers love sparkly new toys. Part of the point
of Scala is it satisfies both constituencies by running on the
familiar JVM.

Miles, charging money to support users who wish to run Scala IDE on
Java 5 sounds like a good business model for you. If Scala no longer
supports 5.0 *at all* then that and many other business models will be
cut off ;-)

Neil

Ricky Clarkson wrote:
> I look forward to providing our customers/my boss with the build of
> Java 6 for 32-bit Macs that you will supply in order to make your
> assertion true.

OK, good point (even if it seems that Snow Leopard has a 32 bit jvm,
see:
http://superuser.com/questions/31526/does-snow-leopard-provide-java-6-fo...
I don't have a Mac, so it's just googling, and must be verified)

But it seems that the dual distribution is a must have, I only hope that
this will not be too time consuming.

Ah, great. Thanks for that. So 32-bit Intel Macs can run Snow
Leopard, and hence get Java 6. The only ones left out in the cold
will be PowerPC Macs, which have not been on sale since 2007. We now
plan on making one 'final' release of our software for Java 5 then
we'll switch. So by the time Scala 2.8 comes out we'll probably not
care about Java 5. :)

2009/9/24 Francois :
> Ricky Clarkson wrote:
>>
>> I look forward to providing our customers/my boss with the build of
>> Java 6 for 32-bit Macs that you will supply in order to make your
>> assertion true.
>
> OK, good point (even if it seems that Snow Leopard has a 32 bit jvm, see:
> http://superuser.com/questions/31526/does-snow-leopard-provide-java-6-fo...
>  I don't have a Mac, so it's just googling, and must be verified)
>
> But it seems that the dual distribution is a must have, I only hope that
> this will not be too time consuming.
>

On Thu, Sep 24, 2009 at 11:01 AM, Neil Bartlett <njbartlett@gmail.com> wrote:

On Thu, Sep 24, 2009 at 10:43 AM, Francois <fanf42@gmail.com> wrote:
> Each time the argument that company will prefer to continue to use old
> version of Java, because new one bring them too few things, I can't stop
> wondering if these companies are likely to be early users of new
> technologies such as Scala. I was wondering the same thing about the
> argument against reified generics in java 1.5...

Don't make the mistake of treating large companies as monoliths. IT
departments of course dislike Java 6, Scala and other new-fangled
nonsense, whereas developers love sparkly new toys. Part of the point
of Scala is it satisfies both constituencies by running on the
familiar JVM.

Miles, charging money to support users who wish to run Scala IDE on
Java 5 sounds like a good business model for you. If Scala no longer
supports 5.0 *at all* then that and many other business models will be
cut off ;-)

Neil

+1 On charging for 1.5 support
I have depressing recent experience of working on java 1.4, with code that allegedly couldn't be upgraded to 1.5 as the 1.3->1.4 upgrade had hurt performance.  Probably due to all the explicit garbage collection that dated back to Java 1.2.  They were also running weblogic on the Sun JVM because the version of solaris in use was too old to support jrocket...
I won't name names or state the industry, but given the size of bonuses they were handing out, and the amount of government funding they've recently received, these are people who very much can and should pay licensing fees, they have no right to expect free help out of the mess they created.

On Sep 24, 2009, at 12:10, Miles Sabin wrote:

> On Thu, Sep 24, 2009 at 9:55 AM, Christos KK Loverdos
> wrote:
>> Let us all just keep in mind that industry does not follow versions
>> that
>> easily. Benefitting from 1.6 is great and this is what I will have
>> in my
>> personal laptop (and try to push to customers) but we need to make
>> sure the
>> 1.5 world gets the same treatment as the 1.6 world. At least for a
>> year, I
>> would propose.
>
> Bear in mind that Sun isn't offering a straightforward download for
> 1.5 any more (you have to register first) and warn prominently when
> you do eventually get to the download link that 1.5 (for non-paying
> customers) will be EOL'd on the Oct 30th 2009.
>
> Should our commitment to 1.5 be greater than Sun's?
>

Yes, unless Oracle comes and says to everyone, "look, you MUST all
upgrade, or else..." AND then people follow right away.

Think about it in another way: Are you going to tell people, "Look, I
have a super language and IDE but it only follows the latest Java
version, so either you upgrade or you lose it" ?

Not my decisions to make, certainly, but I am giving a perspective.

BR
Christos

On Thu, 2009-09-24 at 14:02 +0300, Christos KK Loverdos wrote:
> Think about it in another way: Are you going to tell people, "Look, I
> have a super language and IDE but it only follows the latest Java
> version, so either you upgrade or you lose it" ?

I didn't want to get into this debate, but I felt like the above is a
bit misleading. Java 6 is the latest version, but it was released on the
11th of December 2006. It will be about 3 years by the time Scala 2.8.0
is released.

Best,
Ismael

I say shoot for 1.6, but as a kind gesture there could be a scala-2.8-anachron.jar targeted to 1.5

On Thu, Sep 24, 2009 at 1:08 PM, Ismael Juma <mlists@juma.me.uk> wrote:

On Thu, 2009-09-24 at 14:02 +0300, Christos KK Loverdos wrote:
> Think about it in another way: Are you going to tell people, "Look, I
> have a super language and IDE but it only follows the latest Java
> version, so either you upgrade or you lose it" ?

I didn't want to get into this debate, but I felt like the above is a
bit misleading. Java 6 is the latest version, but it was released on the
11th of December 2006. It will be about 3 years by the time Scala 2.8.0
is released.

Best,
Ismael

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

Perhaps I didn't phrase the initial message in this thread very well ...

The point I was trying to draw attention to is that the combination of
implicits which (accidentally or deliberately) retro-pimp 1.6 methods
onto 1.5 core Java classes is likely to be,

* problematic if rt.jar versions aren't matched between compile and runtime.

* hard to check for, because compilation against the older rt.jar
won't show up the problem because the pimping will mask missing
methods.

Cheers,

Miles

I think targeting 1.6, in and of itself, is a reasonable decision.
I think targeting 1.6 when the community has been under the impression that 1.5 would be the target is a communications and relations disaster.

On Thu, Sep 24, 2009 at 2:56 AM, Lukas Rytz <lukas.rytz@epfl.ch> wrote:

For 2.8 there will most likely be two releases (1.5 and 1.6) because actors can profit
from 1.6, and the Array.newInstance interface is different.

However, the 1.5 release might be only a "plain" scala build without sbaz or eclipse,
only compiler and library, similar to what we did before with 1.4. People running a
server on 1.5 can take scala-library.jar from there, but the recommended version
would be 1.6.


Lukas




On Thu, Sep 24, 2009 at 00:59, Miles Sabin <miles@milessabin.com> wrote:

See the #2380 and in particular my comment #6 here,

 https://lampsvn.epfl.ch/trac/scala/ticket/2380#comment:6

There seem to be several long term solutions, none of them entirely
satisfactory,

* Provide JDK-version specific builds.
* Build releases against the minimum required JDK version.
* Special-case methods like String.isEmpty (maybe via an annotation)
and compile in a backwards compatible way.
* Avoid uses of methods like String.isEmpty altogether.

I've gone for the last of these as the fix for #2380 for 2.7.7 because
we're out of time for the others. But it's really not at all
satisfactory because it's difficult to statically check that there are
no uses of such 1.6 methods.

Suggestions welcome ...

Cheers,


Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype:  milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

--
http://erikengbrecht.blogspot.com/

>>>>> "Alex" == Alex Blewitt writes:

Alex> Whilst 1.5 is EOL next month, practically speaking, large
Alex> companies may continue to use it for a while.

There's been a lot of talk about conservative large companies using old
JVM's. I'd like to add that they aren't the only ones.

I write software for use in schools, and schools often can't afford the
latest and greatest, or are still running old software due to inertia
and neglect. In particular, there are lots of Macs in schools that are
still running Mac OS X 10.4 and 10.5, which restricts them to Java 1.5.
(Yes I know there was a Java 1.6 for 10.5, but it only worked on 64-bit
Intel Macs, and tended to work poorly even on those.)

There's a limit to supporting old stuff, of course. We don't support
Mac OS X 10.2 and 10.3 anymore, and I wouldn't expect 1.5 to be
supported past Scala 2.8.

I wouldn't care if the 1.5 build was compiler-and-library-only. But I
have a question. If there are separate 1.5 and 1.6 builds of Scala 2.8,
will the 1.5 build also work on 1.6? If it doesn't, that will create
serious difficulties for us, because:

- We'll need to distribute two different versions of our application.
(Or come up with some diabolically clever launching scheme that can
dynamically choose and load the right Scala library.)

- Worse, the applet version of our application, which our users copy
onto their own web servers, will have to bifurcate too. I don't know
what we'd do about this; we'd probably decide it was unacceptable and
we'd have to rewind to the last version of Scala that worked on 1.5
without problems.

I sincerely hope that the Java 1.5 build of Scala 2.8 will work on both
1.5 and 1.6.

On Thu, Sep 24, 2009 at 14:17, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Alex" == Alex Blewitt <alex.blewitt@gmail.com> writes:

 Alex> Whilst 1.5 is EOL next month, practically speaking, large
 Alex> companies may continue to use it for a while.

There's been a lot of talk about conservative large companies using old
JVM's.  I'd like to add that they aren't the only ones.

I write software for use in schools, and schools often can't afford the
latest and greatest, or are still running old software due to inertia
and neglect.  In particular, there are lots of Macs in schools that are
still running Mac OS X 10.4 and 10.5, which restricts them to Java 1.5.
(Yes I know there was a Java 1.6 for 10.5, but it only worked on 64-bit
Intel Macs, and tended to work poorly even on those.)

There's a limit to supporting old stuff, of course.  We don't support
Mac OS X 10.2 and 10.3 anymore, and I wouldn't expect 1.5 to be
supported past Scala 2.8.

I wouldn't care if the 1.5 build was compiler-and-library-only.  But I
have a question.  If there are separate 1.5 and 1.6 builds of Scala 2.8,
will the 1.5 build also work on 1.6?

I don't see a reason why it shouldn't.
Lukas

 

 If it doesn't, that will create
serious difficulties for us, because:

- We'll need to distribute two different versions of our application.
 (Or come up with some diabolically clever launching scheme that can
 dynamically choose and load the right Scala library.)

- Worse, the applet version of our application, which our users copy
 onto their own web servers, will have to bifurcate too.  I don't know
 what we'd do about this; we'd probably decide it was unacceptable and
 we'd have to rewind to the last version of Scala that worked on 1.5
 without problems.

I sincerely hope that the Java 1.5 build of Scala 2.8 will work on both
1.5 and 1.6.

--
Seth Tisue @ Northwestern University / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

>>>>> "Lukas" == Lukas Rytz writes:

>> I wouldn't care if the 1.5 build was compiler-and-library-only. But
>> I have a question. If there are separate 1.5 and 1.6 builds of
>> Scala 2.8, will the 1.5 build also work on 1.6?

Lukas> I don't see a reason why it shouldn't.

Famous last words :-)

I suggest that whatever automated testing is done should test all three
setups: 1.5 build running on 1.5; 1.5 build running on 1.6; 1.6 build
running on 1.6.

On Thu, Sep 24, 2009 at 02:40:57PM +0200, Lukas Rytz wrote:
> > I wouldn't care if the 1.5 build was compiler-and-library-only. But I
> > have a question. If there are separate 1.5 and 1.6 builds of Scala 2.8,
> > will the 1.5 build also work on 1.6?
>
> I don't see a reason why it shouldn't.

There is an opportunity for subtle badness if we unlucky our way into
another situation like isEmpty on String (where the method is pimped
onto String via an implicit in 1.5, but actually exists in 1.6) if the
two methods don't do exactly the same thing, because compiling with 1.5
and running on 1.6 will use the implicit version but compiling with 1.6
will use the built-in version. A same named method with slightly
different behavior is likely a lot worse than a missing method error.

For sure 1.5 on 1.6 should work, but these annoying intersection points
will have to have an eye kept upon them. Another 1.5/1.6 tidbit that I
have seen break a fair bit of code is the appearance of java.io.Console
in 1.6, because the very common "import java.io._" followed by
"Console.println" no longer works. (But that's a compile time issue.)

On Thu, Sep 24, 2009 at 17:31, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Lukas" == Lukas Rytz <lukas.rytz@epfl.ch> writes:

 >> I wouldn't care if the 1.5 build was compiler-and-library-only.  But
 >> I have a question.  If there are separate 1.5 and 1.6 builds of
 >> Scala 2.8, will the 1.5 build also work on 1.6?

 Lukas> I don't see a reason why it shouldn't.

Famous last words :-)

:-D
 

I suggest that whatever automated testing is done should test all three
setups: 1.5 build running on 1.5; 1.5 build running on 1.6; 1.6 build
running on 1.6.

absolutely, I'll keep it in mind.
 

--
Seth Tisue @ Northwestern University / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

Miles Sabin wrote:
> Should our commitment to 1.5 be greater than Sun's?

Sun is a java source but it's not the only JDK developer. I vote for
problem with 32bit macs - a lot of our clients uses them, and for my
company it's not an option to require JDK 1.6 now. We've even supported
OS9 two years ago (big companies in japan, a lot of old macs).

Miles Sabin wrote:
> Should our commitment to 1.5 be greater than Sun's?

Sun is a java source but it's not the only JDK developer. I vote for
problem with 32bit macs - a lot of our clients uses them, and for my
company it's not an option to require JDK 1.6 now. We've even supported
OS9 two years ago (big companies in japan, a lot of old macs).