Language Integrated Query do C#. A Oracle tem planos de fazer algo semelhante para Java ?

Eu desconheço por completo, embora já tenha ouvido falar muito sobre Linq.
Quais as vantagens do Linq sobre um ORM nos moldes do JPA?

É bem mais prático de escrever e infinitamente mais legível do que Criteria. E ao contrário do HQL, a expressão permite refatoracao, por ser direto da linguagem e não uma string a ser interpretada.

Tendencia? Isso existe há uma década no C#. Depois que finalmente Java adotou lambda expressions, a Oracle poderia sim investir em algo parecido para JPA. Fora banco de dados, acredito que tenha algumas situações que vocês já possam tirar algum proveito de lambda expressions do Java a partir da versão que implementaram isso.

Sobre o que é suficiente. Pra mim tanto em Java quanto .NET, para bd relacional SQL é o suficiente.

Não é a Oracle que define isso, é o JCP, depende da comunidade Java abraçar. Um caminho seria fazer um fork do OpenJDK, implementar e submeter a sugestão.

Entendi, mas acredito que tenha que vir algum investimento/patrocinio pra ninguém trabalhar de graça.

Sim, em algum ponto isso depende de um grande player abraçar a ideia, tipo uma Apache ou Eclipse Foundation.

Pessoalmente gosto da idéia de trabalhar com banco de dados usando diretamente as estruturas de dados nativas da linguagem, ao invés de strings, objetos ResultSet, frameworks ORM.

Mas não sei se a Oracle tem planos de fazer Java menos OO.

Eu gostaria se eles fizessem algo no java para gerar JSON e XML.

É bem mais simples, o que pode ser uma vantagem ou não, dependendo do seu ramo de atuação.

Com relação a performance, não creio que LINQ resolve o problema de N+1 queries.

Você fala tipo Codable no Swift 4?

Acho que esse não é o foco do LINQ, mas sem dúvida seria bom ter no Java também.

Quem desenvolve com C# não tem nenhuma reclamação da linguagem?
Quem desenvolve em RoR não tem reclamações?
Quem desenvolve em Go também não?

Tudo, absolutamente tudo, sempre terá quem goste e quem odeie.
Entre os que gostam, sempre terá coisas que desagradam e coisas que são motivos de glórias.

Se você acha que o active record é a melhor coisa do mundo, por que insiste em algo que não tem isso?
Se Ling e C# são maravilhosos, por que perde tempo com o java?
Se Kotlin resolve todos os problemas que o java tem, então foca no kotlin.

Qual a razão de insistir em uma linguagem falida, pesada, lenta e cheia de problemas, com atualização tão lenta?

Enquanto se olhar para uma linguagem ou IDE sem ser pelo viés de que aquilo é uma ferramenta e é voltada para N coisas, feitas de Y maneiras e não serve para outras X e não faz de Z formas, a ______________ (insira ali sua linguagem mais odiada) vai seguir sendo ruim para você.
É o mesmo que querer que um martelo corte a grama: pode funcionar, mas vale a pena tentar?

Dias atrás eu respondi uma questão sobre performance de banco de dados e se bancos NoSQL seriam viáveis para uma necessidade específica.
Eu respondi que, se fosse eu, migrava tudo para MongoDB (que é o NoSQL que mais conheço, embora não seja especialista).
A negativa do sujeito que postou foi baseada em algumas características dos bancos de dados relacionais, algo como “se eu tenho uma publicação publicada por A e compartilhada por B, caso A edite, como vou refletir em B?”. É óbvio que ele só estava pensando no modelo estruturado, onde há tabelas e chaves estrangeiras, primárias e etc.
Se ele conhecesse um pouquinho só do modelo NoSQL, veria que isso é muito mais simples e que as chaves são desnecessárias nesse caso.

O que quero dizer é que, quando se quer desenvolver em uma linguagem, deve-se olhar o mundo pelo modo de ver daquela linguagem.
É como aprender um idioma, como o coreano, não basta decorar significados isolados e frases prontas, é preciso pensar em coreano para ser fluente.

Não curto nada que não me deixe escrever SQL diretamente, mas pra galera que usa é possível resolver N+1 queries com Fetch por exemplo, no caso do NHibernate, pois depende da implentação de cada ferramenta. Claro que na prática é uma zona, a maioria escreve sem se preocupar com o que de fato está sendo gerado. LINQ é expressivamente ótimo, mas só gosto de usar para objetos em memória.

Qual motivo pra não curtir se referir a determinada informação no banco da maneira mais expressiva do ponto de vista do seu programa, ou seja, usando uma estrutura de dados nativa da própria linguagem?

Entendo o argumento de que não compensa usar para aplicações simples (CRUD), e de fato, string é a forma mais expressiva quando se escreve queries avulsas no terminal, mas no caso de uma aplicação mais complexa, não da pra ser tudo baseado em string e ResultSet né?

@rmendes08 estamos falando de LINQ.

tem um exemplo disso ? que linguagem que trabalha dessa maneira ?

Não entendi, ou estou por fora do que você está falando. Trabalho com bd relacional, uso SQL e PL/SQL diretamente. Apesar de conhecer e ter que lidar com isso, fujo de query de ORM, seja LINQ to NHibernate, QueryOver, HQL, Criteria, etc. Já outras formas estou por fora, do que estaria falando?

Eu prefiro o termo ‘integrado’ em vez de ‘direto’.

PL/SQL tem uma linguagem de consulta integrada chamada SQL.

Estou dizendo não vejo motivo pra não querer uma linguagem de consulta integrada na sua linguagem de propósito geral também.

Ter uma linguagem de consulta integrada na linguagem é uma forma mais expressiva de trabalhar com banco de dados do que qualquer framework ORM.

Estava pensando em LINQ to SQL.

Sobre Linq to SQL, nunca mais vi ninguém usando para novas aplicações, pra mim já tinha sido descontinuado. É bem mais limitado do que NHibernate ou Entity Framework.

Se está querendo dizer o que citou sobre o Swift 4, isso ai estou por fora mesmo, nunca trabalhei com iOS.

Alguns pontos: O Linq to SQL (que pode ser confundido com o linq (no linq existe muitas divisões como linq to sql, linq to object, linq to xml) que gera SQL no Entity Framework) é um camada de persistência, muito boa, não é descontinuada, e não é que ela não é muito utilizada, a grande questão dessa camada é que só funciona com SqlServer e por isso a maioria das pessoas preferem utilizar uma ORM que possa trocar o banco e a aplicação funcionar do mesmo jeito é mais por essa limitação, mas, sinceridade é muito rapido as operações CRUD e as consultas e integração com StoredProcedure

Excelente pergunta.

Acho que não, eu lembro quando foi lançado no .NET foi assim um melhoria incrivel na codificação e grandes melhorias em todos os aspectos e desse momento em diante não vi esforço do mundo Java fazer isso … é uma pena.

É LINQ to SQL um framework? ou uma biblioteca? ou um recurso nativo da linguagem?

Não sei. Mas se é mais limitado que um framework então deve ser uma bosta.

É comum precisar trocar de fornecedor de banco de dados? Nunca vi.

O que vejo muito é programador querendo usar banco de dados SQL pra todo tipo de problema: busca em texto, processar json, como variável global, arquivo de configuração.

é mais comum do que você imagina…!

é um Framework ORM e não é uma bosta, só que é para ser utilizado com SqlServer somente!

Leitura:

https://msdn.microsoft.com/en-us/library/bb425822.aspx

Deve ser uma decisão de negócio. A MS não ganha nada se um monte de chumpizeiro usar a tecnologia em outros banco de dados.

Componente do próprio .NET Framework. Pra quem trabalha com modelo OO, o mapeamento via Linq to SQL é bem limitado. Última vez que vi alguem adotando isso foi por volta de 2008-09. Quem trabalha com modelo OO profissionalmente usa NHibernate ou Entity Framework. Pra mim que trabalho diretamente com SQL e sem modelagem OO, prefiro o Dapper.

Outra visão erronea … os Framework ORM principal da Microsoft funciona para qualquer banco é só ter o provider implementado em quem faz isso não é a Microsoft são as empresas que possui banco de dados. A Microsoft só disponibiliza a interfaces de implementação e hoje tudo que é em relação ao desenvolvimento .NET Microsoft no âmbito .NET CORE é Open Source

A Microsoft em seus Docs tem um artigo no ano de 2017 ou seja ano Passado:

https://docs.microsoft.com/pt-br/dotnet/framework/data/adonet/sql/linq/

Dizer que não é utilizado não é uma verdade, tanto é que o desenvolvimento nunca deixou de existir e é parte integrante, se você utilizar o Banco SQL Server é bem útil e outra coisa a Microsoft não joga fora o que ela fez, por motivo de manutenção de sistemas legados e isso é uma vantagem.

Apesar que esse não é o foco da pergunta, porque, o cara pergunta o linq no raiz que engloba inclusive esse provider de acesso ao banco.

Mas em Java que é o foco também não vejo esforço de melhoria nesse aspecto, acho o desenvolvimento de melhorias muito lento e deve ter alguma razão que eu desconheço…

Tudo bem sobre sua experiencia, mas eu nunca mais vi ninguem adotando LINQ to SQL para novos projetos. Não é questao de jogar fora, legado é legado, mas o foco e encorajamento ter passado a ser para usar e evoluir o Entity Framework, mesmo que somente para SQL Server.

A minha intenção maior é informar para que a pessoa possa saber que isso existe e que não é bem assim alguns pontos, realmente em C# eu sou desde da versão 1.0, então eu vivencio isso a muito tempo, um exemplo (saindo de novo do foco) é WebForms a Microsoft atualizou ele esse ano, ou seja, é o mesmo cenário deste, mas, se eu for começar em fazer algo já vou direto para MVC ASP.Net Core é uma tendencia pegar (teoricamente falando) a melhor solução e eu te entendo quando diz “não vejo mais ninguém utilizando” mas, não é porque é ruim e sim porque não evoluiu para outros bancos o seu provider é só para SQLServer e isso é visto pelos desenvolvedores a maior desvantagem … Claro quem Entity Framework ou FluentNhibernate são mais evolutivos e muito utilizados concordo nesse aspecto.

Vale lembrar que até PHP tem um camada linq em um pacote acredito que é falta de interesse mesmo!

Existir existe, mas quem evoluiu de verdade foi o Entity Framework, a exemplo do code-first.

Concordo sobre a falta de interesse no caso do Java, um dos motivos acredito ter sido o atraso da linguagem. Só agora na altura que está o campeonato investir nisso fica difícil, embora não impossível.