No more primitives in Java 10?

[Fabrizio Giudici]

http://java.dzone.com/articles/oracle-discusses-features-java

(hey, just read, didn't check whether it's accurate, a joke, or what)

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Jan Goyvaerts]

That's long overdue if you ask me. But then again, for when is release 10 scheduled ? :-)

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

[Chris Phelps]

IIRC, at JavaOne they were talking about a release every other year. So 8 in 2013, 9 in 2015, and 10 in 2017?

-C

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Moandji Ezana]

This isn't actually new: Simon Ritter gave the same (or similar) talk at JAX London back in November. Slide #41 lists the proposed unified type system:

"No more primitives, make everything objects"

Moandji

[Cédric Beust ♔]

Personally, I care a lot more about making sure that boxing/unboxing is efficient than being able to write "1.toString()" (which I suppose is the meaning of "No more primitives"?).

-- 

Cédric

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Fabrizio Giudici]

On Mon, 19 Mar 2012 18:17:57 +0100, Cédric Beust ♔ <ced...@beust.com>
wrote:

> Personally, I care a lot more about making sure that boxing/unboxing is
> efficient than being able to write "1.toString()" (which I suppose is the
> meaning of "No more primitives"?).

I hope that too.

[Cédric Beust ♔]

Personally, I care a lot more about making sure that boxing/unboxing is efficient than being able to write "1.toString()" (which I suppose is the meaning of "No more primitives"?).

-- 

Cédric

On Mon, Mar 19, 2012 at 10:11 AM, Moandji Ezana <mwa...@gmail.com> wrote:

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Fabrizio Giudici]

On Mon, 19 Mar 2012 17:32:54 +0100, Chris Phelps <cjp...@gmail.com> wrote:

> IIRC, at JavaOne they were talking about a release every other year. So 8
> in 2013, 9 in 2015, and 10 in 2017?

It seems so.

[Cédric Beust ♔]

Personally, I care a lot more about making sure that boxing/unboxing is efficient than being able to write "1.toString()" (which I suppose is the meaning of "No more primitives"?).

-- 

Cédric

On Mon, Mar 19, 2012 at 10:11 AM, Moandji Ezana <mwa...@gmail.com> wrote:

To unsubscribe from this group, send email to javaposse+...@googlegroups.com.

[Reinier Zwitserloot]

The trick is partly a JVM optimization (make boxing/unboxing very efficient. Basically, find locations where a box op is followed by an unbox op, and eliminate the both of them. Make sure this works across method boundaries (i.e. to call a method, my method boxes up a primitive, then the other method unboxes it).

That, and generics integration, i.e. allowing you to write List<int>. In order to make this fast, you can't use new ArrayList<int>();, you'd have to use a static method that can return an implementation backed by an int array. However, if the above optimization is pushed through, you shouldn't suffer any performance penalties using the List<int>'s generified API calls.

[Roland Tepp]

Actually, the quote that I liked about the original article at  http://www.theregister.co.uk/2012/03/07/oracle_java_9_10_roadmap/ was this:

A push for modular Java has already taken place, with the OSGi. Ritter said Oracle is looking at compatibility with the OSGi, so that an OSGi bundle gains the ability to run as a Java module.

So they have put aside the petty half-political squabbles with IBM and finally started working with the currently de-facto existing standard modularisation technology...

Good for us all...

[Reinier Zwitserloot]

No, jigsaw continues as planned. There has always been the goal that jigsaw is simple and flexible enough that OSGi ought to be capable of spitting out files that are legit modules. What this requires of OSGi is not as of yet clear. It'll be one of:

* Nothing needed at all; OSGi modules work verbatim. This would require a number of unfortunate design brainfarts to make work (i.e. OSGi's silly standard for what strings in version numbers mean, and, in fact, OSGi's version scheme in general, which is not compatible with any number of versioning schemes already used out there), which is why this was never touted as a likely option, and, as far as I can tell, crowd OSGi is unhappy with anything except this.

* It is possible java will be capable of translating OSGi modules to jigsaw modules, possibly even on the fly (i.e. transparently). I consider this last one the most likely optino.

* OSGi modules work with only a minor update to the OSGi tools. Nothing changes for OSGi module builders. (i.e. the same as the option above, but OSGi is supposed to do the work).

* OSGi modules work with only a minor update to the OSGi tools. Some changes for OSGi module builders.

Join the jigsaw-dev mailing list for a steady stream of commit logs and some discussion if you'd like to know more details.

[Simon Ochsenreither]

Hi Reinier,

has something happened in regard to some criticized requirements like having class files somewhere which some dynamic languages where unhappy about? Earlier versions where also quite mixed up with Java-the-legacy. Has this been fixed?

Bye,

Simon

[Simon Ochsenreither]

Java-the-legacy.

Ooops. Freudian slip. I meant Java-the-language of course.

[Reinier Zwitserloot]

Well, there's still module-info.java but the syntax of the contents of this file aren't actually java. It looks java-ish, with brackets and semicolons and such, but it's not java, not in the slightest. The 'module' keyword remains in limbo (it would be a 5th access level; less public than 'public', with 'public' serving as the signal that this is in fact reachable from outside the entire module, and 'module' being what public is now), that's tightly wound up with java the language, at least more or less. Nobody is stopping scala etc from adding something for this.

jigsaw module files are a from-the-ground-up redesign of jar files. They are now opaque (no longer 'zip files', i.e. oracle is free to change whatever they want), and class files will or might become legacy concepts, as they aren't the speediest choice these days. If javac emitted files in a different fashion, booting up a large java app would be significantly faster. This part in particular has all sorts of backwards issues with it, but presumably all those old APIs (such as java agents which get to change class files, ClassLoader.defineClass, etc) will continue to be supposed, with the speedier new format shortcut taken only if none of these features end up being used.