Ask questions and see you at July 1st, 8 pm CET: youtube.com/c/bienadam
Also checkout recent episode:
Please keep the questions as short and as concise as only possible. Feel free to ask several, shorter questions. I will also cover some questions in my "shorts" youtube.com/@bienadam/shorts between the shows.
Upcoming airhacks.tv events are also going to be announced at meetup.com/airhacks
New: the airhacks.tv discord server: discord.gg/airhacks
Pooling
@Stateless EJBs are pooled. CDI doesn't use pooling from what I know. @Dependent (the default) and @ApplicationScoped could be used instead as stateless classes. Again, if the direction is to move to CDI, what's the right way to replace @Stateless? Wouldn't @ApplicationScoped perform worse because it's a singleton?
Simplified use case: classes that manipulate a state, like a vehicle assembly line where each assembler is ready to receive many parts lists.
@??? // Stateful, RequestScoped...
class Parts {
List<Wheel> wheels;
List<Window> windows;
List<Door> windows;
List<Axis> axes;
// ...
}
@??? // Stateless, ApplicationScoped...
class WheelAssembler {
@Inject
Parts parts;
void assembleFrontWheels(int num) {
for (int i = 0; i < num; i++) {
parts.wheels.get(i).connect(parts.axes.get(i));
}
}
void assembleRearWheels(int num) { /* connect num wheels to rear axis */ }
}
@??? // Stateless, ApplicationScoped...
class WindowAssembler {
@Inject
Parts parts;
void assembleFrontWindows(int num) { /* connect num windows to front doors*/ }
void assembleRearWindows(int num) { /* connect num windows to rear doors */ }
}
Separation of @Entity and beans
We're told not to mix @Entity and EJB/CDI annotations on the same class. For classes that both hold data and have a behavior that requires injections, how should they be modeled? Splitting the data from the behavior looks like requiring data-oriented over object-oriented design (I'm not against).
Simplified use case: each automotive part (there are hundreds such parts) has its data and a function that is called on it from another class. Here is the approach for 2 of these classes.
In plain OO Java:
class ActionRegistar {
List<Action> actions;
void registerAction(Action action) { actions.add(action); }
}
class Wheel {
int size;
public void roll(ActionRegistar registar) {
Action roll = doRoll(size);
registar.registerAction(roll);
}
}
class Horn {
int volume;
public void honk(ActionRegistar registar) {
Action honk = doHonk(volume);
registar.registerAction(honk); // fined if too loud!
}
}and in Jakarta:
@Stateful/@RequestScoped
class ActionRegistar {
List<Action> actions;
void registerAction(Action action) { actions.add(action); }
}
@Entity
class Wheel implements Part {
int size;
// can't add roll() here because no injections (unless using CDI lookup)
}
@???
class WheelAction implements Action {
@Inject
ActionRegistar registar;
public void roll(Wheel wheel) {
Action roll = doRoll(wheel.size);
registar.registerAction(roll);
}
}
// similar for HornIf this is any good to begin with, how would I get the action class from the data class? Like this?
@ApplicationScoped/@Stateless
class ActionPerformer {
@Inject
private Instance<Action> instance;
void performAction(Part part) {
switch (part) { // pattern matching for switch
case Wheel wheel -> {
WheelAction action = instance.select(WheelAction.class).get();
action.roll(wheel);
}
case Horn horn -> {
HornAction action = instance.select(HornAction.class).get();
action.honk(horn);
}
// case...
};
}
}
Questions asked at geecon session: "Containerless, Bloatless, YAML-less, Serverless Java #slideless" (https://2024.geecon.org/speakers/info.html?id=894) / https://youtu.be/qw7mgPE-SdQ?si=Jue1Wd2Zz7khffC5 :
The time machine, questions from 24th airhacks.tv from Mar 07, 2016:
Questions gist: https://gist.github.com/AdamBien/ad9e7cdc110c634489ca
"Adam, do you think Java is losing space in the development of database engines? What do you see in Java development that will remedy this?" via (http://youtube.com/bienadam): https://studio.youtube.com/video/vAI_29c-p8M/comments
Hi Adam,
I have several questions about CDI and EJB in Jakarta 10 (or 11). I split them into different comments. Feel free to skip between them to others' questions and come back to them later.
Passivation
@StatefulEJBs can be passivated. Is passivation still considered useful? It requires all the object graph to be Serializable, which is something Java is trying to move away from. CDI's@ConversationScoped,@SessionScopedand@RequestScopedcan also hold state, but aren't passivated. Is there a reason to use@Statefulconsidering that the trend is to move from EJB to CDI?Simplified use case: 5 users need to guess a number that the server generates. Each client sends its guess, the server waits until all clients send their guesses, then returns a win/lose response to each client. How should the class that holds the guesses be annotated?