Two of the board members who voted Altman out worked for think tanks backed by Open Philanthropy, a tech billionaire-backed foundation that supports projects preventing AI from causing catastrophic risk to humanity: Helen Toner, the director of strategy and foundational research grants for Center for Security and Emerging Technology at Georgetown, and Tasha McCauley, whose LinkedIn profile says she began work as an adjunct senior management scientist at Rand Corporation earlier this year. Toner has previously spoken at conferences for a philanthropic movement closely tied to AI safety. McCauley is also involved in the work.
https://www.washingtonpost.com/technology/2023/11/18/sam-altman-ilya-sutskever-openai/
Sutskever helped create AI software at the University of Toronto, called AlexNet, which classified objects in photographs with more accuracy than any previous software had achieved, laying much of the foundation for the field of computer vision and deep learning.
https://www.washingtonpost.com/technology/2023/11/18/sam-altman-ilya-sutskever-openai/
He recently shared a radically different vision for how AI might evolve in the near term. Within five to 10 years, there could be “data centers that are much smarter than people,” Sutskever said on a recent episode of the AI podcast “No Priors.” Not just in terms of memory or knowledge, but with a deeper insight and ability to learn faster than humans.
https://www.washingtonpost.com/technology/2023/11/18/sam-altman-ilya-sutskever-openai/
At the bare minimum, Sutskever added, it’s important to work on controlling superintelligence today. “Imprinting onto them a strong desire to be nice and kind to people — because those data centers,” he said, “they will be really quite powerful.”
https://www.washingtonpost.com/technology/2023/11/18/sam-altman-ilya-sutskever-openai/
⇧ え～っと...
AIの進化に対する脅威について、考慮するのがデータセンターだけの閉じた世界で良いって言うんなら、脅威と感じた段階でデータセンターを外部から遮断して、AIとの接触も遮断してしまえば、人類に対して危害が及ぶことは無くなるとは思うんだが...
ちょっと、上記だけだと、具体的な懸念点が分からんし、OpenAIという企業の懐事情が分からんので何とも言えんのだけど、
- AIのモデル生成に利用するデータセンターだけの問題である
- 開発に充てる資金は十分にある
という状況であるならば、
- 発展重視型のモデル生成用のデータセンター
- 安全重視型のモデル生成用のデータセンター
の2つを用意して、2つのプロジェクトを並行して進めれば良いんじゃないのって思ってしまうのだけど。
AIモデルを何某の端末にインストールするようなアプリケーションを提供していないという前提で、クライアント・サーバーモデルのような感じで、自分たち（OpenAI）が管理してるサーバーでだけAIモデルを管理しているんであれば、OpenAIという企業内の閉じた世界でAIの脅威に対して対応できそうな気もするんだが...
“What happened at OpenAI today is a board coup that we have not seen the likes of since 1985 when the then-Apple board pushed out Steve Jobs,” Ron Conway, a longtime venture capitalist who was one of the attendees at OpenAI’s developer conference, said on X. “It is shocking, it is irresponsible, and it does not do right by Sam and Greg or all the builders in OpenAI.”
https://www.washingtonpost.com/technology/2023/11/18/sam-altman-ilya-sutskever-openai/
⇧ まぁ、現状、世の中（ネットの情報）に出回っている情報の真意が定かでないので、今ある情報だけから判断すると、そういう解釈になっちゃうよね。
JavaのRecordクラス（JEP 395: Records）とは？
OpenJDKの公式の情報だと、
History
Records were proposed by JEP 359 and delivered in JDK 14 as a preview feature.
In response to feedback, the design was refined by JEP 384 and delivered in JDK 15 as a preview feature for a second time. The refinements for the second preview were as follows:
-
In the first preview, canonical constructors were required to be
public. In the second preview, if the canonical constructor is implicitly declared then its access modifier is the same as the record class; if the canonical constructor is explicitly declared then its access modifier must provide at least as much access as the record class. -
The meaning of the
@Overrideannotation was extended to include the case where the annotated method is an explicitly declared accessor method for a record component. -
To enforce the intended use of compact constructors, it became a compile-time error to assign to any of the instance fields in the constructor body.
-
The ability to declare local record classes, local enum classes, and local interfaces was introduced.
This JEP proposes to finalize the feature in JDK 16, with the following refinement:
- Relax the longstanding restriction whereby an inner class cannot declare a member that is explicitly or implicitly static. This will become legal and, in particular, will allow an inner class to declare a member that is a record class.
Additional refinements may be incorporated based on further feedback.
⇧ という経緯らしいのだけど、結局、JDK 16で決定稿になったと考えて良いんかね？
つまり、Recordクラスの機能を使うには、最低限、JDK 16以上である必要があるってことで良いのかどうかが知りたいのよね。
一応、日本のJava Championの1人目である櫻庭祐一さんが公開してくださっている資料によると、
⇧ 仕様策定完了の一覧で「395: Records（16）」となっているので、JDK 16からRecordクラスを正式に利用できるという認識で良さそうな気がする。
Java Championはと言うと、
Javaチャンピオン（ジャバチャンピオン、Java Champion）はオラクルがスポンサーするプロジェクトで、コミュニティにより選ばれたJavaテクノロジーならびにJavaコミュニティのリーダーのこと。JavaチャンピオンはオラクルがJavaを発展させるためのフィードバックやアイディアを提供する機会を得る。
Javaチャンピオンの選考方法
新しいJavaチャンピオンの推薦があると、メーリングリストにて投票が行われる。現Javaチャンピオンはプラスまたはマイナスの票を投じることができ、2週間の投票期間中に3以上のプラス票があり、マイナス票がなければJavaチャンピオンとして確定する。マイナス票が1つでも入ると、投票を継続するか停止するかどうかの議論が行われる。2週間のプラス票が3に満たない場合は議論が行われる。
⇧となっているので、日本におけるJavaテクノロジーの有識者という認識で良いかと。
なので、信頼できる情報と考えて差し支えないかと。
一応、Oracleの公式のドキュメントによりますと、
5 レコード・クラス
Java SE 14のプレビュー機能として導入されたレコード・クラスは、通常のクラスよりも厳格ではなくプレーン・データ集計をモデル化するのに役立ちます。Java SE 15では、ローカル・レコード・クラスなどの追加機能を使用してプレビュー機能が拡張されています。
https://docs.oracle.com/javase/jp/15/language/records.html#GUID-6699E26F-4A9B-4393-A08B-1E47D4B2D263
5 レコード・クラス
特殊な種類のクラスであるレコード・クラスは、通常のクラスよりも少ない手間でプレーン・データ集計をモデル化するために役立ちます。
https://docs.oracle.com/javase/jp/16/language/records.html#GUID-6699E26F-4A9B-4393-A08B-1E47D4B2D263
⇧ とあるので、JDK 16から正式に利用できるようになったという認識で良いかと。
一応、OpenJDKの公式の情報で、Recordクラスを利用する際の主だった制約について、
Rules for record classes
There are numerous restrictions on the declaration of a record class in comparison to a normal class:
-
A record class declaration does not have an
extendsclause. The superclass of a record class is alwaysjava.lang.Record, similar to how the superclass of an enum class is alwaysjava.lang.Enum. Even though a normal class can explicitly extend its implicit superclassObject, a record cannot explicitly extend any class, even its implicit superclassRecord. -
A record class is implicitly
final, and cannot beabstract. These restrictions emphasize that the API of a record class is defined solely by its state description, and cannot be enhanced later by another class. -
The fields derived from the record components are
final. This restriction embodies an immutable by default policy that is widely applicable for data-carrier classes. -
A record class cannot explicitly declare instance fields, and cannot contain instance initializers. These restrictions ensure that the record header alone defines the state of a record value.
-
Any explicit declarations of a member that would otherwise be automatically derived must match the type of the automatically derived member exactly, disregarding any annotations on the explicit declaration. Any explicit implementation of accessors or the
equalsorhashCodemethods should be careful to preserve the semantic invariants of the record class. -
A record class cannot declare
nativemethods. If a record class could declare anativemethod then the behavior of the record class would by definition depend on external state rather than the record class's explicit state. No class with native methods is likely to be a good candidate for migration to a record.
⇧ まとめられていますと。
Recordクラスの用途としては、
Summary
Enhance the Java programming language with records, which are classes that act as transparent carriers for immutable data. Records can be thought of as nominal tuples.
⇧「immutable data」として扱って欲しいということのようです。
そもそもとして、Javaで、
- プリミティブ型
- 参照型
- Immutable
- Mutable
の関係を「MECE（Mutually Exclusive and Collectively Exhaustive）」的に整理しているような情報が無いので、
⇧ 現場は大混乱ですと。
動的型付け言語であるJavaScriptの界隈では、
⇧ 整理してくださっている方がおられますが、静的型付け言語であるJava界隈でも上図のようなマトリックス表が欲しいところですな。
とりあえず、JavaのRecordクラスは、「Immutable」で扱って欲しいということのようです。
JavaのRecordクラス（JEP 395: Records）ってJPAとの相性が最悪ってこと？
ネットの情報を漁っていて、
The record class is final and automatically provides all the infrastructure code required by a data class.
https://thorben-janssen.com/java-records-embeddables-hibernate/
But you might have already recognized that the definition of a record doesn’t fulfill JPA’s requirements of an entity. These are:
- It has to be a top-level class annotated with @Entity.
- It can’t be final.
- It has to provide a public or protected, parameter-less constructor.
- It has to declare an identifier that consists of at least 1 attribute.
https://thorben-janssen.com/java-records-embeddables-hibernate/
⇧ とあって、
上記の2つの機能の要件が噛み合っていないですと。
最終的な結論として、
Conclusion
Java records are simple carrier classes for immutable data. That makes them look like an obvious candidate for entity classes and embeddables.
https://thorben-janssen.com/java-records-embeddables-hibernate/
But the JPA specification requires entity and embeddable classes to be non-final and to provide a parameter-less constructor. A record class doesn’t fulfill these requirements. It’s implicitly final and provides a constructor with a parameter for each record component. Due to that, the JPA specification only allows you to use record classes as DTO projections.
https://thorben-janssen.com/java-records-embeddables-hibernate/
⇧ 上記のような結論が出ていて、なかなか苦肉の策というか、工夫が必要な状況らしい。
Spring Data JPA側でも、
⇧ EntityクラスとRecordクラスの2つを用意する二重管理みたいな感じになってしまっている模様。
う～む、「JPA（Jakarata Persistence API）」以外の「ORM（Object Relational Mapping）」ライブラリでは、どういう対応してるのかが気になるが、データベースとのやり取りが絡んでくると、モデルの設計が複雑になってきますな...
データベースについては、
- 参照系
- 更新系
で、どうしてもデータの更新の話が出てくるから、Recordクラスのオブジェクトを上手いこと、全く更新の必要のないモデルとして切り出す必要が出てくると。
まぁ、最悪、Recordクラスのインスタンスを再作成して、データベース側のデータを更新って感じで誤魔化す感じになるんかな、インスタンス生成によるパフォーマンス劣化は考慮しない感じで。
何やら、
Yorm is a basic ORM-alike framework designed to work with Java Records, without class generation, neither annotations. In the world of microservices, there is a tendency to have very contained logic within every service, and hence reduced databases, that in many cases are simply no more than several tables with not that many fields. Java Records usually are a perfect fit for basic CRUD operations, and here is where Yorm shines.
Yorm needs at least Java 17.
⇧ JavaのRecordクラス（JEP 395: Records）を考慮したライブラリが出てたっぽい。
Yorm has been tested with Snowflake, and it works as long as the table has no primary keys, and the Jvm is run with the option --add-opens java.base/java.nio=ALL-UNNAMED
⇧ 上記の説明だと、Snowflake限定での動作確認では、「主キー（primary key）」が無くても動作したってことみたいね、そもそも、Snowflakeの「主キー（primary key）」と一般的な「RDBMS（Relational DataBase Management System）」の「主キー（primary key）」で、差異があるのかどいうかが分からんのだが...
学習コストが嵩むなぁ...
ちなみに、Wikipediaで、
This is a list of well-known object–relational mapping software.
⇧「ORM（Object Relational Mapping）」のsoftwareの一覧ページが作成されておりました。TypeScriptなどの「ORM（Object Relational Mapping）」のライブラリについては触れられていないようですね。
Javaだと、
- Apache Cayenne, open-source for Java
- Apache OpenJPA, open-source for Java
- DataNucleus, open-source JDO and JPA implementation (formerly known as JPOX)
- Ebean, open-source ORM framework
- EclipseLink, Eclipse persistence platform
- Enterprise JavaBeans (EJB)
- Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects
- Hibernate, open-source ORM framework, widely used
- Java Data Objects (JDO)
- JOOQ Object Oriented Querying (jOOQ)
- Kodo, commercial implementation of both Java Data Objects and Java Persistence API
- TopLink by Oracle
⇧ 上記が紹介されておりますと。
「JPA（Jakarata Persistence API）」については、
Java Persistence API（JPA）とは、関係データベースのデータを扱うJava SEおよびJakarta EE（旧・Java EE）のアプリケーションを開発するためのJava用フレームワークである。
JPAは、以下の3つの部分から成る。
JPAのリファレンス実装はEclipseLinkとして実装されている。
Jakarta Persistence (JPA; formerly Java Persistence API) is a Jakarta EE application programming interface specification that describes the management of relational data in enterprise Java applications.
Persistence in this context covers three areas:
- The API itself, defined in the
jakarta.persistencepackage (javax.persistencefor Jakarta EE 8 and below) - The Jakarta Persistence Query Language (JPQL; formerly Java Persistence Query Language)
- Object/relational metadata
The reference implementation for JPA is EclipseLink.
The final release date of the JPA 1.0 specification was 11 May 2006 as part of Java Community Process JSR 220. The JPA 2.0 specification was released 10 December 2009 (the Java EE 6 platform requires JPA 2.0). The JPA 2.1 specification was released 22 April 2013 (the Java EE 7 platform requires JPA 2.1). The JPA 2.2 specification was released in the summer of 2017. The JPA 3.1 specification, the latest version, was released in the spring of 2022 as part of Jakarta EE 10.
⇧ とあるように、英語版のWikipediaの方の説明にあるように、途中から名称が変わっていますと。
脱線しましたが、Javaに限って言うと、既存の「ORM（Object Relational Mapping）」ライブラリ以外を検討していく感じになってくるのかな？
勿論、データベースとのやり取りに関しては、Recordクラスを使わないっていう選択肢もあるとは思うけども、そもそも、JDK 16以降でなければRecordクラスが使えないってのもありますし。
分水嶺に来ているんですかね。
毎度モヤモヤ感が半端ない...
今回はこのへんで。
