Awesome, clear and simple explanation of something I've been scratching my head over trying to understand DTOs and Entities in relation to adding new data to a database. Thank you, truly.
i am learning java the easy way, but i wonder how come you dont have so much subscribers!!! Anyway keep giving good content. Love u from Botswana, Africa.
Thank you so much. I’m a new subscriber and every video you post is like a refresher to me in a way. You are a great help to everyone in the community, whatever experience and programming level they are right now.
John you are amazing man. Was learning from you when I started programming 2 and a half years ago. Got a job. Programming for a year and a half now and still come back here when I need something properly clarified. Beauty.
Great video, very clear. Thank you, John! A couple questions: Is a Java bean a POJO? It implements another class. Or would it cease to be one only if it implemented an *outside* class? (Since Serializable is a "built-in" Java class, a bean can still count as a POJO.) Also, what if one of the fields of the class has a data type that depends on (or is) another class? Would that still be a POJO?
In my experience a DTO is basically a simple class, usually a POJO, whose job is to work as a middle-man between two representations. For example, you might have a web service request with a certain class structure, and also a database entity with a similar, but separate class structure. To avoid tightly coupling those two classes together, we typically will have a DTO (data transfer object) class that essentially holds the same data, and create mappings from the request to the DTO, and from the DTO to the database entity. And perhaps mappings for the other way around too, if you also want to be able to return those database entries to the user. So a DTO is more of a name for the purpose of the class, rather than aspects of what the class has or doesn't have like a pojo or javabean.
Good example of a DTO that I currently use is using one to store data in the database, and using the other to pull data via the API. The DTO is used to pull data so I don't potentially expose unnecessary information to the end user. The Entity, however, can store more information in the DB, without potentially exposing that information to the end user.
@@vignesh3184 I believe its so the object is recreated the same, regardless of the target. That is, if you serialize a Java object, any other language can deserialize the object and receive the information. Could be incorrect or missing info, but that seems to be the application.
I searched what is a Java Bean something new I learned even though I self taught myself Java 10 years ago, and still don't know what a Java Bean is lol, I've come across your content before however very well explained.
POJO Plain Old Java Object. Thank you, Started in 1983 programming, no schooling, just hobby. Missed a bunch of history. I remember putting a dot on a blank screen and it was brilliant, amazing, awesome. ;)
Two corrections for Java Bean: 1. Fields don't need to be private -2. Getters & Setters are not required for a class/object- These requirements are do's and don'ts from some design patterns or recommendations. Not part of bean definition.
as per the Oracle spec there must be getters and setters. "Properties are always accessed via method calls on their owning object. For readable properties there will be a getter method to read the property value. For writable properties there will be a setter method to allow the property value to be updated. Thus even when a script writer types in something such as “b.Label = foo” there is still a method call into the target object to set the property, and the target object has full programmatic control."
@@drcl7429 Following those lines in the spec: "So properties need not just be simple data fields, they can actually be computed values". Irrespective internally how java invokes/compiles, getters & setters are not required to define a bean. From newer Java standards, "record" is perfectly valid Java Bean even though it doesn't have any methods.
Your videos are awesome, with clear and concise explanation, thank you! I hope you make a video about beans and inversion of control, just because I think your explanation will be clearer than other's.
@@dronephone9934 pojo refers to java clases that do not depend on any infrastructure apart from the core java language (string, list, map and such). Any class that has a dependency on, for example, a specific framework (ejb) or specification (a servlet) is not a pojo. If you have a domain in your project you may decide to implement it using pojos. That does not forbid using another class in your domain as a dependency, for example though inheritance. If in your domain there in a concept "animal", you can have a class "Animal" and a class Cat extends Animal, both being pojos. Please read about the origin of the term from Fowler (martinfowler/bliki/POJO.html)
Great video. I was going to ask if a Java bean can be a pojo but you answered that when you typed implements serialize. Speaking of which, if you haven’t already, can you do a video on serialize
Yep, the implements Serializable is kind of a gray area because of what you're talking about. Lots of people will say that all Java beans are pojos, but not all pojos are Java beans. But technically the Serializable thing makes that not true. But in this case, Serializable is such a "built-in"Java functionality that many overlook that and still call them pojos, which is definitely understandable. You seem to have a keen eye for these types of subtleties in these videos! And I'll look into what a video on serialization might be like to see if it'll work.
I'd say java bean cannot be a pojo. Definition of POJO I learned was that POJO is basically a class that has no other fancy name. So if you can call it a bean, you no longer can call it a pojo.
John thanks very much.. I misunderstood for many years that POJO and Java Beans are same. May be if i had found your channel earlier i would have even started loving Java earlier than this.
Funny, according to your def. a JavaBean cannot be a POJO because a POJO cannot implement an interface but JavaBeans have to implement Serializable. Gotcha :D You just have to love Javas consistency
I noticed that too. My question for @CodingWithJohn: does it cease to be a POJO because it implements another class, or because it implements an *outside* class? Serializable is a built-in Java class.
@@johnkeck I would say bean is not a pojo simply because it's a bean. Class has to fulfill some requirements to be a bean, while pojo does not follow any requirements of any framework.
Well well, that's funny, I just discovered that I didn't know either what was a POJO. I'm currently in a training session and I asked if POJO and java beans were the same and unfortunately I got the "yes" anwser. But I was, somehow, skeptical, because why would we use 2 differents terms for EXACTLY the same thing ? Well now I know, they are not the same ^^ nice video.
So, if I make a Calculator class and create simple methods for each operation, then it is a POJO? An example: The class: public class Calculator A method: public static void add(double num1, double num2) { System.out.println(num1 + num2); }
Hi John, can you please explain a little bit more what do you mean when you said a POJO mustn't use external libraries? For instance, if I used CollectionUtils from apache library inside the class, that would make my class NOT a POJO, right?
I hate private, to many times I have to rely on reflection to do things to do the things I want. Also I think in most cases something should be protected over private. But what do I know...
A pojo can extend other class and a pojo can implement an interface. The fundamental aspect of a pojo is that a pojo does not depend on any external component, in particular framework components like ejb or hibernate. It can depend on other classes that belong to the same domain. Cat extends Animal {} is a pojo if Animal is defined in the same package as Cat. But if you are using a 3rd party library that introduces Animal to your application, then Cat is not a pojo. The idea of pojo is that you can express your domain using classes that only depend on other classes of your domain. The idea of pojos appeared after ejb 1, that forced you to extend from ejb classes to implement your domain entities. It made your domain a mess, forcing your domain classes to implement behaviour imposed by a framework. With pojos your domain is cleaner, implementing domain specific behaviour, and the framework related behaviour moved outside the domain.
When you were talking about the Cat class not being a Java Bean you said that the String and int were not private. Aren't variables private by default unless specified otherwise?
Nice Explanation !! Can we Modify the POJO Class based on the properties file? I am trying to add/inject/remove properties files fields in my POJO class from a property file. Is it possible?
I have similar experience and also must say this term does not come up too often. Generally if you read about some framework or library you are considering using and documentation says it works with POJO, that basically means you can pass any kind object you want to it and it will work.
@@sureshmanne7245 You could even say it makes it more pojo. When you don't write your own toString method, you're inheriting it from java.Object class. The base class of all java classes. So by implementing it yourself, you're taking a bit of this inheritance away. And if you look at the rules for a pojo: you're not adding inheritance (no extends), you're not implementing an interface (no implements keyword) and you're not adding some external annotation kung-fu. @Override is no external annotation magic.
Or what if we use Lombok getter, setters annotations on a pojo. Can we call it as PoJo..? If we create no args constructor and getters and setters does it still qualify as PoJo?
What about a class has everything else (like private fields, getters and setters and public no args constructor) but. Doesn't implement serializable.. ? Can we call it as PoJo or is it still a Java bean?
Java has many builtin methods to write objects directly. For example you can pass a whole object to some socket or to file. Java checks if the object implements serialziable, and if so, it will convert it to some binary form that can be written to file, send via network or something. By writing "implements serializable" you are saying that this object can be safely stored and then reverted. For example if there is possibility of a cyclic dependency (A has reference to B, B references C and C references back to A) serialization of that object would get stuck on that so you should not mark that object as serializable.
At end when you add implement serializable to make the class a java bean, doesn't this make the class not POJO anymore? Because the class is implementing something now
Yeah he answered that from another comment, he said: "serializzable is such a built-in java feature, that even if it is not a pojo, we sometimes call it so"
Since there is still no video here is the answer: POJO may contain not only properties, but also methods and logic, sometimes truly complicated. DTO stands for Data Transfer Object. It is used to send data from one module, service, application to another, 4 example via message brokers such as RabbitMQ. DTO contains only necessary data, no methods except may be getters and setters. As a very primitive example, you have class Employee, that contains a lot of information about the person: age, name, address, birthday, sex, bank account, salary etc. And also it has methods such as promote(), fire() and so long. When it is time to pay your worker you send information to another application, that actually pays the money. It doesn't need age, sex and phone number of employee. The only thing it does is sends money from your account to another one that you provide. So BOTH(!!!!) your application and the salary module have the same let call it PaymentDto class. That class only has bankAcconutNumber and salary properties. Otherwise the payment application should have the entire Employee class implemented to be able to receive data from you, automatically map it to own class and process one. PaymentDto is the object that you actually send from one module to another, creating it using only required data from your employee object. So it is an object that is used to transfer the data. Data Transfer Object. DTO.
Is using an external class possible in a POJO class? For example, If the POJO class uses Map or List from the java.url lib or having a field with a with a user defined class type.
Using standard libraries like that probably doesn't disqualify it from being called a "pojo". It's definitely worth noting though, that it's still a somewhat fuzzy definition. And don't let it stop you from using what you need to use in your class. Even if it might not be called a pojo anymore, having your application function properly and be coded in a clean way is a way bigger priority.
So Cat class was turned into a Java Bean and it's no more a POJO, since it's implements a interface now So It means POJO is never a Java Bean and Java Bean is never a POJO
Hey John, can a POJO contain an import statement? As I understand a POJO is a standalone, independent java class. So having an import statement makes it “NOT” POJO?
Would a class with a member with a non-JDK non-primitive type still be a POJO? Surely, that class couldn't be used by itself: you'd need the other class, as well
I think this definition is still made up. POJO, historically, is just an alternative to an Enterprise Java Bean. Not extending or implementing may have referred to EJB specific base classes and interfaces.
Awesome, clear and simple explanation of something I've been scratching my head over trying to understand DTOs and Entities in relation to adding new data to a database. Thank you, truly.
i am learning java the easy way, but i wonder how come you dont have so much subscribers!!! Anyway keep giving good content. Love u from Botswana, Africa.
Thank you so much. I’m a new subscriber and every video you post is like a refresher to me in a way. You are a great help to everyone in the community, whatever experience and programming level they are right now.
Thank you so much for the short precise and clear elaboration with example.
Could you please provide the difference between ValueObject and POJO?
Value object should be immutable and in your code two value objects with same values set to their fields should be treated as equal.
John you are amazing man. Was learning from you when I started programming 2 and a half years ago. Got a job. Programming for a year and a half now and still come back here when I need something properly clarified. Beauty.
Your explanantions are quite elegant. Thanks for doing these. Would love to know more about Serializable.
Great video, very clear. Thank you, John! A couple questions:
Is a Java bean a POJO? It implements another class. Or would it cease to be one only if it implemented an *outside* class? (Since Serializable is a "built-in" Java class, a bean can still count as a POJO.)
Also, what if one of the fields of the class has a data type that depends on (or is) another class? Would that still be a POJO?
Can you talk about DTO (Data transfer object classes). I see that people has many definitions for that
In my experience a DTO is basically a simple class, usually a POJO, whose job is to work as a middle-man between two representations. For example, you might have a web service request with a certain class structure, and also a database entity with a similar, but separate class structure. To avoid tightly coupling those two classes together, we typically will have a DTO (data transfer object) class that essentially holds the same data, and create mappings from the request to the DTO, and from the DTO to the database entity. And perhaps mappings for the other way around too, if you also want to be able to return those database entries to the user.
So a DTO is more of a name for the purpose of the class, rather than aspects of what the class has or doesn't have like a pojo or javabean.
Good example of a DTO that I currently use is using one to store data in the database, and using the other to pull data via the API. The DTO is used to pull data so I don't potentially expose unnecessary information to the end user. The Entity, however, can store more information in the DB, without potentially exposing that information to the end user.
Can you explain why entity class need to be serializable?
@@vignesh3184 I believe its so the object is recreated the same, regardless of the target. That is, if you serialize a Java object, any other language can deserialize the object and receive the information.
Could be incorrect or missing info, but that seems to be the application.
@@vignesh3184 entity classes don't need to be serializable
I searched what is a Java Bean something new I learned even though I self taught myself Java 10 years ago, and still don't know what a Java Bean is lol, I've come across your content before however very well explained.
Man, your videos are just so good! Congratulations on your work!
thank you for clearing my long awaited doubt.
POJO Plain Old Java Object. Thank you, Started in 1983 programming, no schooling, just hobby. Missed a bunch of history. I remember putting a dot on a blank screen and it was brilliant, amazing, awesome. ;)
I sugguest you do a java sudoku solver tutorial. It’s a common lab assignment in data structures and algorithms from what I’ve been hearing.
I wrote one in Python in college years ago actually, but haven't in Java yet. If I can make it concise enough for UA-cam that's a great idea!
Figured it out, and it's this week's video. Thanks for the suggestion, hope you like it! ua-cam.com/video/mcXc8Mva2bA/v-deo.html
What a nice video. it was very usual for me, because in the web arent mutch informations availible. Short and onPoint!
Two corrections for Java Bean:
1. Fields don't need to be private
-2. Getters & Setters are not required for a class/object-
These requirements are do's and don'ts from some design patterns or recommendations. Not part of bean definition.
as per the Oracle spec there must be getters and setters.
"Properties are always accessed via method calls on their owning object. For readable properties there will be a getter method to read the property value. For writable properties there will be a setter method to allow the property value to be updated. Thus even when a script writer types in something such as “b.Label = foo” there is still a method call into the target object to set the property, and the target object has full programmatic control."
@@drcl7429 Following those lines in the spec: "So properties need not just be simple data fields, they can actually be computed values". Irrespective internally how java invokes/compiles, getters & setters are not required to define a bean. From newer Java standards, "record" is perfectly valid Java Bean even though it doesn't have any methods.
@@munagalavrr As far as I know, no further spec beyond 1.01 was published by Oracle, Sun or JavaSoft.
@@drcl7429 Sorry, you are correct, thanks for correcting me. I have updated my original comment.
that guy made a fancy sounding name for a simple java object so prudes would use it more, love it.
Hello John, I would like you to explain why it is necessary to make the attributes private.
Thank you. Its was the best understanding pojo and Serializable. Good luck
Thanks for putting it in simple words!
Finally somebody explains it in layman’s terms for novices like myself. Thank you!
Your videos are awesome, with clear and concise explanation, thank you! I hope you make a video about beans and inversion of control, just because I think your explanation will be clearer than other's.
Clear, precise and straight to the point!
And wrong.
@@pablog5738 care to correct any points he made ?
@@dronephone9934 pojo refers to java clases that do not depend on any infrastructure apart from the core java language (string, list, map and such). Any class that has a dependency on, for example, a specific framework (ejb) or specification (a servlet) is not a pojo. If you have a domain in your project you may decide to implement it using pojos. That does not forbid using another class in your domain as a dependency, for example though inheritance. If in your domain there in a concept "animal", you can have a class "Animal" and a class Cat extends Animal, both being pojos. Please read about the origin of the term from Fowler (martinfowler/bliki/POJO.html)
Love your short videos. Thanks
Great video. I was going to ask if a Java bean can be a pojo but you answered that when you typed implements serialize.
Speaking of which, if you haven’t already, can you do a video on serialize
Yep, the implements Serializable is kind of a gray area because of what you're talking about. Lots of people will say that all Java beans are pojos, but not all pojos are Java beans. But technically the Serializable thing makes that not true. But in this case, Serializable is such a "built-in"Java functionality that many overlook that and still call them pojos, which is definitely understandable.
You seem to have a keen eye for these types of subtleties in these videos!
And I'll look into what a video on serialization might be like to see if it'll work.
I'd say java bean cannot be a pojo. Definition of POJO I learned was that POJO is basically a class that has no other fancy name. So if you can call it a bean, you no longer can call it a pojo.
Very eloquent and concise! Do you have any advice on how to use JPA with multiple java beans?
John thanks very much.. I misunderstood for many years that POJO and Java Beans are same. May be if i had found your channel earlier i would have even started loving Java earlier than this.
Excellent as always.
Simple, clean and clear.
And I clearly learned something.
Thank you John. 😉
Funny, according to your def. a JavaBean cannot be a POJO because a POJO cannot implement an interface but JavaBeans have to implement Serializable. Gotcha :D You just have to love Javas consistency
Java bean cannot be a pojo, true, where is that 'gotcha' part?
I noticed that too. My question for @CodingWithJohn: does it cease to be a POJO because it implements another class, or because it implements an *outside* class? Serializable is a built-in Java class.
@@johnkeck I would say bean is not a pojo simply because it's a bean.
Class has to fulfill some requirements to be a bean, while pojo does not follow any requirements of any framework.
@@johnkeck serializable is an interface.
john can u slam your ad at the end of the vid? thanks. Quality video nevetheless.
My super man bro... do you have anything about Spring ? please please... You are my lifesaver ...
Well well, that's funny, I just discovered that I didn't know either what was a POJO. I'm currently in a training session and I asked if POJO and java beans were the same and unfortunately I got the "yes" anwser. But I was, somehow, skeptical, because why would we use 2 differents terms for EXACTLY the same thing ? Well now I know, they are not the same ^^ nice video.
Thank god I now have this hidden knowledge critical for an efficient workflow.
Awesome video. Thanks brother
You're so good as always John!
Please make a Spring Boot course.. I'll be the first person to buy it 🙏
Thank you, I love watching your videos.
Great explanation! But what is a Java Bean and what does it serve?
Thanks, a piece of maybe useful information that I can't bring up in an interview without sounding like a knowitall.
Thanks, this was incredibly helpful
So, if I make a Calculator class and create simple methods for each operation, then it is a POJO?
An example:
The class:
public class Calculator
A method:
public static void add(double num1, double num2) {
System.out.println(num1 + num2);
}
Guess technically yes, that's a pojo, but because it has no fields and only a static method, many people would call it a "helper class".
Thanks a lot for all the extra very important infos related to better understand POJO.
What if class Implements Serialization?? Will we still refer to that class as POJO?
Can you do a video about dependency injection?
Very clear explanation. thanks for sharing it.
Great explanation!!! THANK YOU JOHN!!!!
thank you i learn so much through your sessions!
Pojo can implement and extend interface or classes of java
Can you make a video about Jackson library?
Nice video, very simple! thanks!
I love your videos. They are really informative. Thanks!
What about Jave Bean vs POJO vs Spring Bean?
Gracias Mister John....claro y directo al punto.....saludos de los andes peruanos
Hi John, can you please explain a little bit more what do you mean when you said a POJO mustn't use external libraries?
For instance, if I used CollectionUtils from apache library inside the class, that would make my class NOT a POJO, right?
correct.
Great explanation
Make a video about spring
Damn man this was awesome. Thank you.
Short and clear. Thanks.
I hate private, to many times I have to rely on reflection to do things to do the things I want. Also I think in most cases something should be protected over private. But what do I know...
Love the explanation, now I understand well the difference between javaBeen and Pojo.
The explanation is wrong.
@@pablog5738 What is wrong?
A pojo can extend other class and a pojo can implement an interface. The fundamental aspect of a pojo is that a pojo does not depend on any external component, in particular framework components like ejb or hibernate. It can depend on other classes that belong to the same domain. Cat extends Animal {} is a pojo if Animal is defined in the same package as Cat. But if you are using a 3rd party library that introduces Animal to your application, then Cat is not a pojo. The idea of pojo is that you can express your domain using classes that only depend on other classes of your domain.
The idea of pojos appeared after ejb 1, that forced you to extend from ejb classes to implement your domain entities. It made your domain a mess, forcing your domain classes to implement behaviour imposed by a framework. With pojos your domain is cleaner, implementing domain specific behaviour, and the framework related behaviour moved outside the domain.
@@pablog5738 ohh thank you.
When you were talking about the Cat class not being a Java Bean you said that the String and int were not private. Aren't variables private by default unless specified otherwise?
Default is package-private, so the fields can still be accessed by other classes in the same package.
Great Explanation.
Nice.
Please make some videos on spring boot
thanks for this video!
As usual....John is a legend 🙌 👏
I only use POJO so far as i've not learnt the other stuff yet XD. havent had a need to yet with my projects
Nice Explanation !! Can we Modify the POJO Class based on the properties file?
I am trying to add/inject/remove properties files fields in my POJO class from a property file. Is it possible?
I've been programming as a profession for over 15 years and never used that term or heard it being used.
I have similar experience and also must say this term does not come up too often. Generally if you read about some framework or library you are considering using and documentation says it works with POJO, that basically means you can pass any kind object you want to it and it will work.
Thanks. Video was good and helpful
Can we implement toString() in POJO or Java Bean ?
Yes
@@RutgerOlthuis will it not break POJO terminology if we do so?
@@sureshmanne7245 You could even say it makes it more pojo. When you don't write your own toString method, you're inheriting it from java.Object class. The base class of all java classes. So by implementing it yourself, you're taking a bit of this inheritance away.
And if you look at the rules for a pojo: you're not adding inheritance (no extends), you're not implementing an interface (no implements keyword) and you're not adding some external annotation kung-fu. @Override is no external annotation magic.
Or what if we use Lombok getter, setters annotations on a pojo. Can we call it as PoJo..? If we create no args constructor and getters and setters does it still qualify as PoJo?
I notice that a java bean is not a POJO at all as it implements serializable, which breaks the rule of a POJO
Thanks John.👌
What about a class has everything else (like private fields, getters and setters and public no args constructor) but. Doesn't implement serializable.. ? Can we call it as PoJo or is it still a Java bean?
Thank you for this video. Clear explanation
What is seariliable? Please make a video
Java has many builtin methods to write objects directly. For example you can pass a whole object to some socket or to file. Java checks if the object implements serialziable, and if so, it will convert it to some binary form that can be written to file, send via network or something.
By writing "implements serializable" you are saying that this object can be safely stored and then reverted.
For example if there is possibility of a cyclic dependency (A has reference to B, B references C and C references back to A) serialization of that object would get stuck on that so you should not mark that object as serializable.
How can a java bean be a POJO if a java bean depends on the serializable interface?
Thanks
but while you written the word implements serializable you had broken the first rule!!! isnt that????
Great man you are!
Well done :) Thank you
At end when you add implement serializable to make the class a java bean, doesn't this make the class not POJO anymore? Because the class is implementing something now
Yeah he answered that from another comment, he said: "serializzable is such a built-in java feature, that even if it is not a pojo, we sometimes call it so"
Excellent very clear!
Master Shifu, your Java Kung fu is on another level 🙏. Please keep teaching!
- from one of your many online students!
thanks!
Can pojos be serializable?
thanks for the explanation. I am confused between POJO and DTO. could you please help me understanding with a video if possible.
Since there is still no video here is the answer: POJO may contain not only properties, but also methods and logic, sometimes truly complicated.
DTO stands for Data Transfer Object. It is used to send data from one module, service, application to another, 4 example via message brokers such as RabbitMQ.
DTO contains only necessary data, no methods except may be getters and setters. As a very primitive example, you have class Employee, that contains a lot of information about the person: age, name, address, birthday, sex, bank account, salary etc. And also it has methods such as promote(), fire() and so long.
When it is time to pay your worker you send information to another application, that actually pays the money. It doesn't need age, sex and phone number of employee. The only thing it does is sends money from your account to another one that you provide.
So BOTH(!!!!) your application and the salary module have the same let call it PaymentDto class. That class only has bankAcconutNumber and salary properties. Otherwise the payment application should have the entire Employee class implemented to be able to receive data from you, automatically map it to own class and process one. PaymentDto is the object that you actually send from one module to another, creating it using only required data from your employee object. So it is an object that is used to transfer the data. Data Transfer Object. DTO.
@@iyhan1987 thanks for this. Been looking for a concise explanation
@@pt_trainer9244 you are welcome :)
Where were you all those years of confusion? 👏👏👏
Is using an external class possible in a POJO class?
For example, If the POJO class uses Map or List from the java.url lib or having a field with a with a user defined class type.
Using standard libraries like that probably doesn't disqualify it from being called a "pojo". It's definitely worth noting though, that it's still a somewhat fuzzy definition. And don't let it stop you from using what you need to use in your class. Even if it might not be called a pojo anymore, having your application function properly and be coded in a clean way is a way bigger priority.
Thank you for the answer John!
And in my comment I wrote java.url, I meant java.util of course.
So you say a class that extends a POJO can not be a POJO itself? I do not think that is correct.
I agree.
If java bean has to implement serializable interface, does it mean it's no longer POJO according to your definition(POJO can't implement interfaces)?
He said bean class is not a POJO already
@@saranram9225 I think I missed it. about what time he said that?
@@alexhu01 He did not say it.
So Cat class was turned into a Java Bean and it's no more a POJO, since it's implements a interface now
So It means POJO is never a Java Bean and Java Bean is never a POJO
You forgot to explain what is the usage
AMAZING!!!!👍
Hey John, can a POJO contain an import statement? As I understand a POJO is a standalone, independent java class. So having an import statement makes it “NOT” POJO?
I think the class Cat extends java.lang.Object . So cat class is not pojo. 😇
Would a class with a member with a non-JDK non-primitive type still be a POJO? Surely, that class couldn't be used by itself: you'd need the other class, as well
blow my mind always
I think this definition is still made up. POJO, historically, is just an alternative to an Enterprise Java Bean. Not extending or implementing may have referred to EJB specific base classes and interfaces.
Great and simple video! Thank you :)