Dropping support for Java 5/Java 6

On 8/14/11 11:39 AM, Simon Ochsenreither wrote:
> What about Java 6? If Scala will ever decide to ship with some IO
> library Java 7 will probably be the minimum requirement.

Where did you get that idea? There is zero chance of this.

Well, the first Java version shipping with file system support is Java 7. Even just comparing nio.file.Path with its retarded grandfather io.File. Without shipping with additional platform-specific native libraries it just doesn't work. Copying or moving a file, watching a file for changes, traversing a directory, copying files recursively ... just not possible before Java 7. So a potential Scala IO library has either to depend on Java 7 or ship with compiled dll/so files.

> There is zero chance of this.

Of what?

Thanks and bye,


Simon

On 8/14/11 11:39 AM, Simon Ochsenreither wrote:

>> What about Java 6? If Scala will ever decide to ship with some IO
>> library Java 7 will probably be the minimum requirement.

> There is zero chance of this.

Of what?

... of Java 7 being the minimum requirement for the core Scala distribution (in the near future)
(this is strictly my personal interpretation of the quoted lines, but I'm pretty sure it's right)
also, those Java 5 build failures have always been fixed promptly (afaik, they were all instances of the classic String::isEmpty difference between version 5&6)

On Mon, Aug 15, 2011 at 12:17 PM, Adriaan Moors wrote:
> ... of Java 7 being the minimum requirement for the core Scala distribution
> (in the near future)

The sensible thing to do here is to have a separate jar for
functionality that requires nio.2 (i.e. Java 7) and it should probably
start in the incubator.

> also, those Java 5 build failures have always been fixed promptly (afaik,
> they were all instances of the classic String::isEmpty difference between
> version 5&6)

When it comes to Java 5 support, it seems to me that it's time to
retire that once the next major release is out. It's not worth the
maintenance cost as far as I can see.

Best,
Ismael

There were also some Swing-related ones recently.

Hi,

The sensible thing to do here is to have a separate jar for
functionality that requires nio.2 (i.e. Java 7) and it should probably
start in the incubator.

I agree. I would prefer it if the standard library JAR wouldn't get any big additions in the future but would get modularized further (Swing, XML, Parsers, sys, Actors, ...) and shipping with some additional optional JAR files instead, that would make deployment in certain situations much more lightweight (like Android).
But Paul has much more experience in that...

Looking at the situation around Scala IO, I would prefer having either support for at least two backends (JVM, .NET, LLVM, Mozart/Oz) or two completely independent implementations. I don't feel too comfortable basing everything on one underlying implementation. It is just the question who will do the work.

When it comes to Java 5 support, it seems to me that it's time to
retire that once the next major release is out. It's not worth the
maintenance cost as far as I can see.

 I agree. Maybe it can be deprecated for 2.10?

Thanks and bye,

Simon

On 8/15/2011 6:51 AM, Ismael Juma wrote:
> On Mon, Aug 15, 2011 at 12:17 PM, Adriaan Moors wrote:
>> ... of Java 7 being the minimum requirement for the core Scala distribution
>> (in the near future)
>
> The sensible thing to do here is to have a separate jar for
> functionality that requires nio.2 (i.e. Java 7) and it should probably
> start in the incubator.
>
>> also, those Java 5 build failures have always been fixed promptly (afaik,
>> they were all instances of the classic String::isEmpty difference between
>> version 5&6)
>
> When it comes to Java 5 support, it seems to me that it's time to
> retire that once the next major release is out. It's not worth the
> maintenance cost as far as I can see.
>
> Best,
> Ismael
>

I think the need for 1.5 was two years ago, when some major server room
distros like AIX or RH5 were stuck with that. I think that the problem
has mostly faded away. I don't really see any need to stay with 1.5,
but I'm sure that there are one or two people on the planet who might
need it.

But, if I recall correctly, Martin did definitely want to use 1.6's
forkjoin capabilities. I'm all for it.

Bob
(ishmal on irc)

On Mon, Aug 15, 2011 at 4:54 PM, Bob Jamison wrote:
> But, if I recall correctly, Martin did definitely want to use 1.6's
> forkjoin capabilities.  I'm all for it.

Scala includes a copy of fork-join in the distribution (with changed
package names). Also, fork-join was only added to Java 7. I think you
mean that there are some more efficient concurrency primitives used by
fork-join that were only added in 1.6.

Best,
Ismael

Are there any versions of real-time Java that are past 1.5?  I don't know of any, but maybe that isn't an important consideration given that the object creation propensity of Scala prevents most real-time work.

I believe that Azul's JVM is for 1.6; does anyone know about the other specialized-for-giant-workloads JVMs?

  --Rex

On 8/15/2011 11:01 AM, Ismael Juma wrote:
> On Mon, Aug 15, 2011 at 4:54 PM, Bob Jamison wrote:
>> But, if I recall correctly, Martin did definitely want to use 1.6's
>> forkjoin capabilities. I'm all for it.
>
> Scala includes a copy of fork-join in the distribution (with changed
> package names). Also, fork-join was only added to Java 7. I think you
> mean that there are some more efficient concurrency primitives used by
> fork-join that were only added in 1.6.
>
> Best,
> Ismael
>
Ismael,

I think that the difference is that 1.6's impl goes "down to the bone".

Bob

On Sunday, August 14, 2011 2:39:38 PM UTC-4, Simon Ochsenreither wrote:

are there decisions when Scala will stop supporting Java 5?

I've made noise in the past when it seemed like Scala might fully or partly drop Java 5. So I should speak up now and say go right ahead, drop it for 2.10! It doesn't matter to me anymore.
The class of users I represent is people building desktop software and applets for home and school use. And the issue is that the first Mac OS X version to have a usable Java 6 was Mac OS X 10.6. So dropping Java 5 means dropping support for Mac OS X 10.5. As recently as a year ago, that was impossible for us — too many home and school users still on 10.5.  But by the time Scala 2.10 rolls around, it won't be an issue anymore.
-- Seth Tisue | Northwestern University | http://tisue.netlead developer, NetLogo: http://ccl.northwestern.edu/netlogo/