A Classfile API for the JDK

Ғылым және технология

This session discusses an upcoming standard API for parsing, generating, and transforming Java class files.
JEP draft: Class-File API (Preview) ➱ openjdk.org/jeps/8280389
Presented by Brian Goetz - Java Language Architect (Java Platform Group - Oracle) during the JVM Language Summit 2023 (Santa Clara CA).
Make sure to check the • JVM Language Summit 2023 playlist.
Tags: #Java #OpenJDK #JVMLS

Пікірлер: 22

  • @ITV-ITV-
    @ITV-ITV-10 ай бұрын

    I would love to work with someone who can explain complex low-level problems so accessibly and move from the big picture to the details and back with ease as Mr. Brian Goetz does! It would've make my developer career so much easier and enjoyable.

  • @tintifax8531
    @tintifax85319 ай бұрын

    There seems to be a pattern here. Brian's talks tend to have dull and somewhat uninteresting titles, but then turn out to be chock full of extremely well explained software engineering wisdom.

  • @USONOFAV
    @USONOFAV11 ай бұрын

    14:00 Best explanation of how Inversion of Control really works

  • @maruseron
    @maruseron9 ай бұрын

    i'm a simple man. i see brian goetz, i click

  • @kaqqao
    @kaqqao10 ай бұрын

    Gawd, I can't help but think how I wish to just for once work on something where I can iterate many times to get it right, instead of the usual "ship the proof of concept" approach.

  • @askarkalykov

    @askarkalykov

    10 ай бұрын

    And after shopping poc, just fix all the bugs before the next release, and keep in mind that we are going to connect new partners already the next month.

  • @tintifax8531

    @tintifax8531

    9 ай бұрын

    We must be working for the same company. Actually, pretty much all the companies I've worked for.

  • @FostersLagerMorphs
    @FostersLagerMorphs9 ай бұрын

    At19:08, eliminating magic numbers for slots makes the code so much clearer. At 21:40 is the wisdom take-away. I'm excited for this.

  • @michaelsimons6035
    @michaelsimons603510 ай бұрын

    "They took away your IDE like 7 years ago" and what comes afterwards: Even a proper. good sense of human. Great session, thank you!

  • @AhmetMurati
    @AhmetMurati11 ай бұрын

    Great improvements

  • @askarkalykov
    @askarkalykov10 ай бұрын

    Really looking forward to testing that! Will the code generation also be a part of the project? I see the mention of "write" there in JEP summary =)

  • @Alberto_Cavalcante
    @Alberto_Cavalcante10 ай бұрын

    Great presentation! Can't help to think how interesting would be to see this API usage in Kotlin.

  • @bananasba
    @bananasba10 ай бұрын

    It would be strange if you did not have a strict model in the API for something that obviously had a strict model.

  • @DelusionalLogic
    @DelusionalLogic9 ай бұрын

    The lambda builder stuff seems like a solution in search of a problem. All you're doing there is filling in a buffer and passing it to the "assembler". The builder doesn't really seem at add anything. Sure you can then run the lambda twice, but if you'd just stuck with a buffer you wouldn't have to run all that code twice.

  • @JosuaKrause
    @JosuaKrause11 ай бұрын

    cool api. since they designed everything from scratch I find it a bit odd that they have slots as int instead of properly exposing a record type (e.g., SlotId) so you can't accidentally pass an int from elsewhere. It's not like you'd need to do arithmetic on slot ids (if you use the api to create them)

  • @SwarangaSarma

    @SwarangaSarma

    11 ай бұрын

    I would guess the tradeoff is avoiding allocations of trivial types at the expense of some safety. Valhalla may have made it redundant but delaying the API for when Valhalla eventually lands would not have been acceptable. To me it seems they still went with the best choice they had.

  • @lhxperimental
    @lhxperimental10 ай бұрын

    I like how the Java ecosystem is clearing up the technical debt. JVM languages have come and gone, Java has borrowed some of their best parts and made itself better. JDK 21 onwards, Java's future looks bright. Next I would like to see is a culture of less verbosity in code. This is as much a function of coding culture in Java community as much it is about language support.

  • @Dragiux

    @Dragiux

    9 ай бұрын

    Verbosity is fine. It's layered the way it is for a reason so you could swap out the layers.

  • @ttcc5273

    @ttcc5273

    9 ай бұрын

    Java's future does look bright! There is such a thing as good verbosity... I would describe it as 'terse verbosity" that minimizes the possibility of ambiguity in the reader's interpretation. timeout = 50 // could be interpreted as seconds, milliseconds, or minutes by both the reader and the CPU, depending on how it's used timeoutMs = 50 // interpreted as 50ms by the reader, could be interpreted differently by the CPU depending on how it's used timeout = Duration.of(50, MILLISECONDS) // means the same thing to the reader as it does the CPU Like the talk says... "find the primitive" and build outward from that... this reduces "noisy" verbosity and cultivates "terse" verbosity Edit: a lot of "noisy" verbosity is often associated with unwieldy designs - let's call them either "jellyfish" or "sea urchin" designs depending on if they are too amorphous or too rigid. Developers working on large teams often use verbose names to either prop up jellyfish designs... or to fit in with the hierarchical rigidity of a sea urchin design. Verbosity that brings clarity is good... verbosity that doesn't communicate intent or that confuses the reader is probably symptomatic of something deeper

  • @sommyaruproy8405

    @sommyaruproy8405

    6 ай бұрын

    Verbosity should not be reduced. Just use ide

  • @Alperic27
    @Alperic278 ай бұрын

    looks like llvm … … 👍👍👍

Келесі