Contexts & Dependency Injection for Java

Working method for CDI 2.0

Posted by Antoine Sabot-Durand on Oct 06, 2014 | Comments

Work on CDI 2.0 started at the beginning of september. As you may guess, specifying and releasing this new major version is a big challenge.

To put all chance on our side we are looking for a strong commitment from the community (as explained in our previous post). That’s why the way we’ll be organised is very important. Thus, when we started thinking about our working method we came up with the following requirements:

  • Keep the big picture of the spec in mind while working on all detail of each new / modified features

  • Have the right balance between "ideal specification" and the "specification only driven by implementation" approaches

  • Be able to welcome new contributors (even casual ones) without loosing them in spec history or advanced technical details at the beginning

  • Give visibility to third party (other JSR or future implementor) of the spec without forcing them to follow our ML, IRC, JIRA

  • Get feedback from the community easily while designing the spec

To satisfy these points we came to the idea of creating different workshop on big CDI topics (existing and new). To begin we identified these workshops:

  • Parts (modularity) : how we can make CDI more modular by extracting sub part in the spec to allow it to grow without becoming bloated

  • Java SE support : how CDI should work in Java SE and what SPI should we add or standardise to ease its integration in home brewed stacks

  • Events enhancement : bringing asynchronicity or ordering to events. Can it be extended to all Java EE

  • Interceptor & Decorator : AOP support on produced or custom bean. Work with interceptor spec to add AOP on inner call

  • SPI enhancement for integration : give access to all metadata produced by the container, give control of CDI from outside code, support Bean addition / modification @ Runtime

  • Contexts enhancement : go beyond the the thread-bound request-response model used by context today to support new application architecture

  • Java 8 enhancement : see how new features in java 8 (type annotation, annotation repetition, lambdas, streams, default methods, type inference…) could enhance CDI in existing and new features.

To ease this big picture approach we also adopted this following step to deal with each workshop:

  1. Blueprint draft : the workgroup lead propose a draft document describing his global idea of how the future should work

  2. Draft discussion The draft is commented, amended, enhanced by the group which can react to the doc by proposing new ideas. and When people feel ready by the EG

  3. Detailled task / requirement: after the discussion, each adopted concept are translated in on or more tickets in our Jira to follow their realisation to start more detailled discussion

  4. Spec and TCK enhancement: each task is translated to the new specification document and translated to the TCK

Of course these steps are more guidelines than a strong workflow, it’s a way to ease contribution not constraint it. It will probably evolve with time.

On our home page you’ll find the list of each workshop and their current status and links (working doc, Jira EPICS, etc…​). Please feel free to check these links and give your feedback and don’t heistate to contribute with your idea on this documents.

Permalink Comments Tags :methodEG

CDI 2.0 needs you

Posted by Antoine Sabot-Durand on Aug 26, 2014 | Comments

Uncle Duke The work on CDI 2.0 specification is about to start in the coming weeks. We have a lot of ambitious features on the table as you can check in our previous article, but we also have only 18 months to specify and implement them. Without community help, we probably won’t be able to do all the change we are planning, so your contribution is precious to us. In this post I’ll explain the multiple ways you can be part of it, even if you only have a few hours a week to help us and/or are not a CDI, JCP or a Java expert. Let’s check the 3 main question most of you have regarding contribution and try to answer them:

  • Why should I contribute?

  • Is it possible for me to contribute?

  • How do I start contributing?

Why should I contribute to CDI 2.0?

Contributing to a specification like CDI looks like any other Open Source contribution (by the way CDI specification and deliverable are under the Apache License version 2) yet it’s very different. The following points will detail these differences.

Working on Architecture and concepts first

The biggest difference between working on a standard OSS project and a specification is probably the fact that the first job is to write detailled documentation (the specification document). Regarding specification document, the content should be very accurate and respect a certain set of rules among them:

  • use an homogenous style in simple yet understandable english across the doc,

  • as specification cannot be changed easily, the work must be very precise, consequences of a choice must be analysed deeply and ambiguities in definitions shouldn’t exist,

  • stick to Java language Specification (JSL) rules and terms,

  • avoid denormalization: the specification should use cross references to point to an existing definition instead of duplicating it,

  • avoid mentioning how features should be implemented while keeping in mind that specified features will have to be implemented at the end.

Participating to code writing.

Specification is useless without implementations. So after (and sometimes while) thinking, comes code writing. First the API, the code that all specifications will have to implement and then as a proof of concept of the specification we have to provide the RI (reference implementation) and TCK (Technology Compatibility Kit) which is mandatory for developing other implementations. So you can also be useful by contributing to JBoss Weld and the CDI TCK which is the translation of the specification in a test suite. Off course these will ask more time and probably more skills for a contribution.

Contributing to the future of Java EE and Java SE

CDI 2.0 will be part of Java EE 8 but also targets Java SE. Therefore, we’d like to make CDI the Dependency Injection standard for Java. It already plays this role for Java EE. So contributing to the CDI 2.0 specification is a way to be part to the future of Java and Java applications architecture.

Being at the source of a lot of other projects

Working on CDI specification is also a way to indirectly work at (and thus, have impact on) other projects linked to it. The implementations (Apache OpenWebBeans and JBoss Weld) are off course the obvious ones, but today there are a lot of other open source frameworks or projects out there based on CDI. Apache Deltaspike, VRaptor or Openbravo are some example of these (you can also consider most of JBoss Java frameworks which use CDI to be integrated). Working on CDI is a way to help these projects to become better or give you the knowledge to contribute to them in the future to help them getting the best of CDI 2.0 when it will be released.

Is it possible for me to contribute?

Most people disqualified themselves when it comes to contribute to a JSR. The 3 most frequent reason given are:

  • the technical level,

  • the lack of time or,

  • the "paperwork" tied to such a contribution.

Let’s review these "good" excuses that could make one thinks "contributing is not for me"

Technical level

Ok, if you are an absolute beginner in Java and CDI, it will be hard to help without making others loose their time. But as you’re reading these lines, you are probably not an absolute beginner ;). One of our goal on CDI 2.0 is to make the specification as easy as possible to read. So even if you are not a top notch Java specialist, your reading skill and feedback on badly written, ambiguous or hard to understand part will be very precious to the Expert Group. Regarding Java Level, CDI 2.0 will leverage a lot of new features coming with Java SE 8 on which most of the contributors will have very little experience. So, on this topic specialists will be the exception. To make short, the minimum level to contribute is to have a reasonable knowledge on Java (enough to know your unknown and where to look to learn), have already used CDI in development, have a good knowledge of its features (DI, Events, AOP, Extensions…​) and be able to read english. That makes a lot of people qualified to help.

Time

From the previous point you can understand that there is no minimum amount of time for contribution. For instance you can read a specification chapter and propose corrections or remarks on it, it will take you 2 or 3 hours on the 18 months of the specification. Now the best would be to provide a few hours a week. To help people that want to contribute and don’t have much time, we’ll try to provide a monthly synthesis of topics worked on the project to spare their time and avoid the "I’d like to do something but I don’t have time to dig thru all the mailing list and Jira message to figure out what to do". These reports will also be useful for the EG members to have a big picture vision of the work regulary.

Paper work

To be officially enrolled on a JCP Expert Group requires a little paper work. You’ll have to create an account on jcp.org and sign the Java Specification Agreement (JSPA). You’ll probably have to ask you employeer an agreement to contribute. And then ask the spec lead to be part of the JSR. On the JSR side, we never refused a member in the EG in the past and plan to continue like that for the new JSR

The good news is that we also accept non official contributions as any other Open Source project using ASL2. So if you don’t feel like signing JCP stuff, you can still participate to discussion on the Mailing list, the IRC channel or our JIRA site. You can even send pull request on the project. The only difference will be that you won’t be mentioned as a member of the expert group on the JCP website.

So to make short. You can start contributing with no paper work. Stay anonymous during all the project or decide to officially join the EG at any time before the end of the JSR. The only limit would be if you start doing big contribution. In this case we’ll probably ask you to join EG to avoid any future IP issues.

How do I start contributing?

The best place to start is probably the Mailing List, or if you want a more informal you can begin with the IRC channel(#cdi-dev on freenode). All the information regarding communication channel of the spec is detailled on the contribute page.

You also should start reading the existing specification to become familiar with its content and its style.

Finally, as the specification is written in asciidoc (with the excellent asciidoctor implementation), you should also start learning it. The best place is probably the Asciidoctor user manual. As we’re using asciidoctor maven plugin to generate the doc you won’t have to install asciidoc toolchain, only Maven. You’ll also nedd a text editor with optionally plugins to help writing asciidoc. Atom editor with asciidoc language and asciidoc preview plugins is a good solution, but there are plenty of others depending on your taste and current tools.

What’s next?

We are currently preparing the organization of the work around the specification. The goal is to be as efficient as possible regarding contribution. The Mailing List is the best place to stay tuned. In the meantime you can do "homework" with the existing material.

Conclusion?

We are trying to make CDI 2.0 a very open specification to give to the community the possibility to contribute easily to this great project. We are thrilled to count you onboard for any contribution (big or small) you’ll be able to do, making CDI 2.0 your specification.

Permalink Comments Tags :EGcommunitymethod

Conclusion of EG preparation on CDI 1.2

Posted by Antoine Sabot-Durand on Dec 16, 2013 | Comments

Updated on 01/07/2014

We finished to deal with the list of 28 Jira we planned to introduce or not in MR. So 24 of them will be in MR and 4 won’t. The list is also accessible on Jira.

Jira Description Decision Note

CDI-413

Update outdated license

in MR

CDI-408

bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans

in MR

CDI-410

@RequestScoped Javadoc outdated

in MR

CDI-388

Session bean specialization example is not valid

in MR

CDI-376

BeanManager#getProducerFactory return type differs between API and spec

in MR

CDI-377

automatic JSR-330 annotation processing problematic

in MR

Mention needed and perhaps a new feature

CDI-380

Clarify SessionScoped

in MR

We should be less descriptive and like for CDI-381 add a general statement telling that other spec/extensions can change the behavior of built-in scope

CDI-372

clarify behavior of implicit bean archive

in MR

The notion of Bean Archive is introduce in Chapter 12, we should do an introduction before

CDI-320

Clarify whether ProcessAnnotatedType should be fired for annotations

in MR

According to pm it shouldn’t and we should clarify this

CDI-318

@WithAnnotations types can appear on any supertype

in MR

Mainly Javadoc correction on @WithAnnotation

CDI-280

behavior of CDI bean @Specializes session bean is undefined

in MR

could benefit some clarification

CDI-220

Clarify interceptors are not associated with the result of a producer method/field

in MR

CDI-405

Reword the description of @RequestScoped and @ApplicationScoped in section 2.4.1

in MR

CDI-401

Clarify the meaning of "bean class local view"

in MR

CDI-398

Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type

in MR

CDI-392

Clarify when the operations of BeanManager can be called

in MR

CDI-386

Two examples in section 5.2.4 contradict the rules of the same section

in MR

CDI-382

Clarify interceptors are not associated with the result of a producer method/field

in MR

CDI-381

Additional implementations of Request Context

in MR

we should add general statement telling that extension can change the behavior of built-in scope

CDI-406

Make stereotypes bean defining annotations

in MR

CDI-404

adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"

in MR

CDI-389

Revert CDI-85

in MR

we revert to CDI 1.0 behavior but we will have to propose something better in CDI 2.0

CDI-397

Clarify Section 6.6.3 regarding singletons

in MR

we should go a little beyond and check all occurrences of "singleton" in the spec to clarify if it’s an singleton session bean or a singleton scope

CDI-411

CDI conversation activation conflicts with the Servlet spec

in MR

Solution exist at different level. We should at least put a mention in the spec and o something at impl level

CDI-379

Clarify life cycle of RequestScoped

out MR

each spec should detail how they stick to built-in scope

CDI-370

Expand @RequestScoped and @SessionScoped to account for WebSocket

out MR

It’s the responsibility of Websocket spec. We should ensure they take the point before closing the ticket

CDI-77

Clarify what happens when the user creates a unbound recursive injection with Dependent scoped beans

out MR

Container doesn’t have to support this : the ticket should be closed

CDI-395

Public fields in extensions should not be allowed

out MR

it can bring backwards compatibility problem to correct this issue. We should see if impls allows it today. If it’s not the case it could be safely added to the MR
Permalink Comments Tags :EGfeatures