3 ms·

Big Objects is explained in detail in the Java Beans Spec: https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/techn

by brabel 5y ago

Big Objects is explained in detail in the Java Beans Spec: https://www.oracle.com/java/technologies/javase/javabeans-spec.html https://www.oracle.com/java/technologies/javase/javabeans-sp... The idea may have died, but there's still lots of vestiges of it in the Java world. - getters and setters with standardized names - Swing mechanics like EventListeners and PropertyChangeListener - Java Serialization They hoped that a Java bean could be plugged into any UI and be visualized, modified and generally integrated into any app, so you could "buy" beans made by other developers, for example. It was definitely an interesting idea, but things went in a completely different direction, as we know.

_greim_ 5y ago
I think sometimes the abstraction moat around an otherwise good idea definitely repels would-be adopters, which an idea needs to ascend to mainstream success, beyond just technical merit.
the_af 5y ago
Even though the Swing thing was java bean based, the idea of an "event listener" is a still current and sound idea in software development beyond Java. The funny thing about "standardized" getters & setters is that they completely broke OOP and went against this idea that Java was "object oriented". One of the most known articles of the time was the infamous "getters and setters considered evil".
eternalban 5y ago
https://netbeans.apache.org/kb/docs/java/quickstart-gui.html https://netbeans.apache.org/kb/docs/java/quickstart-gui.html It wasn't an "idea". It was/is working tech. How do you think a GUI builder for Java works? In fact, how would you build a UI design tool (in any language) without arriving at the equivalent of a Java Bean (aka Standard Component)? [p.s.] Btw, "Big Object" is a funny way to call a Component. COP is not OOP. (Thus: POJO). So getter/setter naming patterns (so the 'tool' can infer semantics), distinctions made between run-time and design-time, etc. are all perfectly valid concerns for COP and Java Beans a perfectly sensible realization. The problem with the Java community has always been two-fold: 1 - The conceptual disconnect between the target audience of Sun's architects and the said architects. SMI's failing here remains, imo, a pedagogical failure. 2 - A language that facilitates creating complex runnable monstrosities by programmers who would be crushed by the same complexity in other languages. This is an ironic aspect of the Java language. Even newbies can go nuts with complexity.

by brabel 5y ago

_greim_ 5y ago

I think sometimes the abstraction moat around an otherwise good idea definitely repels would-be adopters, which an idea needs to ascend to mainstream success, beyond just technical merit.

the_af 5y ago

Even though the Swing thing was java bean based, the idea of an "event listener" is a still current and sound idea in software development beyond Java. The funny thing about "standardized" getters & setters is that they completely broke OOP and went against this idea that Java was "object oriented". One of the most known articles of the time was the infamous "getters and setters considered evil".

eternalban 5y ago

https://netbeans.apache.org/kb/docs/java/quickstart-gui.html https://netbeans.apache.org/kb/docs/java/quickstart-gui.html It wasn't an "idea". It was/is working tech. How do you think a GUI builder for Java works? In fact, how would you build a UI design tool (in any language) without arriving at the equivalent of a Java Bean (aka Standard Component)? [p.s.] Btw, "Big Object" is a funny way to call a Component. COP is not OOP. (Thus: POJO). So getter/setter naming patterns (so the 'tool' can infer semantics), distinctions made between run-time and design-time, etc. are all perfectly valid concerns for COP and Java Beans a perfectly sensible realization. The problem with the Java community has always been two-fold: 1 - The conceptual disconnect between the target audience of Sun's architects and the said architects. SMI's failing here remains, imo, a pedagogical failure. 2 - A language that facilitates creating complex runnable monstrosities by programmers who would be crushed by the same complexity in other languages. This is an ironic aspect of the Java language. Even newbies can go nuts with complexity.