Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think it's more complicated than assuming there's two groups of stakeholders here. The <a href="http://openjdk.java.net/projects/lambda/" rel="nofollow noreferrer">Project Lambda</a> people seem to be working mostly independently of the Oracle people, <a href="http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/002043.html" rel="nofollow noreferrer">occasionally throwing something over the wall</a> that the Project Lambda people find out indirectly. (Scala, is of course the third stakeholder.)</p> <p>Since the <a href="http://mail.openjdk.java.net/pipermail/lambda-dev/2010-July/001775.html" rel="nofollow noreferrer">latest Project Lambda proposal</a> is to eliminate function types all together, and just create some sort of fancy inference for implementing interfaces that have a single astract method (<strong>SAM</strong> types), I foresee the following:</p> <ul> <li><p>Calling Scala code that requires a Scala closure will depend entirely on the implementation of the <code>Function*</code> traits (and the implementation of traits in general) -- whether it appears to the Java compiler as a SAM (which it is in Scala-land) or whether the non-abstract methods also appear abstract to the JVM. (I would think they currently do look like they're abstract since traits are implemented as interfaces, but I'm know almost nothing about Scala's implementation. This could be a big hurdle to interperability.)</p> <p>Complications with Java generics (in particular how to express<code>Int</code>/<code>int</code>/<code>Integer</code>, or <code>Unit</code>/<code>Nothing</code>/<code>void</code> in a generic interface) may also complicate things.</p></li> <li><p>Using Scala functions to implement Java SAMs will not be any different than it now -- you need to create an <code>implicit</code> conversion for the specific interface you wish to implement.</p></li> </ul> <p>If the JVM gets function types (and Oracle seems not to have eliminated that possibility), it may depend how it's implemented. If they're first class objects implementing a particular interface, then all that Scala needs to do to be compatible is make <code>Function*</code> implement the new interface. If a new kind of type is implemented in the JVM entirely, then this could be difficult -- the Scala developers may wrap them using magic like they currently do for <code>Array</code>s, or they may create create <code>implicit</code> conversions. (A new language concept seems a bit far-fetched.)</p> <p>I hope that one of the results of all of this discussion is that <em>all</em> of the various JVM languages will agree on some standard way to represent closures -- so that Scala, Groovy, JRuby, etc... can all pass closures back and forth with a minimum of hassle.</p> <p>What's more interesting to me is the proposals for <a href="http://mail.openjdk.java.net/pipermail/lambda-dev/2010-May/001306.html" rel="nofollow noreferrer">virtual extension methods</a> that will allow the Java Collections API to use lambdas. Depending on how these are implemented, they may greatly simplify some of the binary compatibility problems that we've had to deal with when changing Scala code, and they may help to more easily and efficiently implement traits.</p> <p>I hope that some of the Scala developers are getting involved and offering their input, but I haven't actually seen any discussion of Scala on the Project Lambda lists, nor any participants who jump out to me as being Scala developers.</p>
    singulars
    1. This table or related slice is empty.
    1. POCompatibility between Scala closures and Java 8 closures
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USKen Bloom
    1. USKen Bloom
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks! Your answer is great. The best thing imho would be if Oracle would just adopt Scala's FunctionX classes so that things are interoperable without any magic. But I guess they will try anything to just _not_ do that.
      singulars
      1. PO
      1. USsoc
    2. CO@soc: Scala's FunctionX classes work well for a number of Scala-specific reasions: (1) our type system hides the distinction between primatives and boxed types, and can fit `void`/`Unit` and `Nothing` into the type system naturally. (2) Definition-site covariance lets us easily pass `FuctionX`s in a natural way using only generics, and Java developers may feel the need to implement a radically new concept in their type system to implement this. (I think that's why Project Lambda is abandoning the idea of a function type.)
      singulars
      1. PO
      1. USKen Bloom
    3. CO@soc: That said, I am disturbed by Project Lambda's apparent lack of discussion with other JVM constituencies.
      singulars
      1. PO
      1. USKen Bloom
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload