JPA properties
Daniel Zwolenski
zonski at gmail.com
Sun Oct 28 04:44:19 PDT 2012
Fair enough. Calling directly onto a database from the client is probably
not an approach I would go for too often or recommend for a lot of use
cases, but hey, if it works for you, great.
All of my comments were with respect to a standard client-server, 3-tier,
JEE architecture (but I don't use EJBs). I personally don't see observable
properties being useful or desirable in the server side of this
architecture (and would recommend a model for the client tier that is
completely decoupled from the data tier, potentially with a DTO pattern at
the service tier to transfer data between them).
Probably all debating a mute point from JFX's perspective though - JFX
properties are what they are and not likely to change. Use them on the
server if you want, don't if you don't.
On Sun, Oct 28, 2012 at 7:54 PM, Tom Eugelink <tbee at tbee.org> wrote:
> Ah. JPA not necessarily is used server only. The whole EJB setup is very
> suited for webapps, but may not be the best setup for desktop apps. The
> EJBs have some drawbacks (insert lenghty discussion here), so I opted to
> create a business model that is distributed as a standalone postprocessed
> jar. It is used in a Swing app, JSF2 webapp, several batch processes for
> a.o. EDIFACT, email, etc. Each with their own entity manager approach.
>
> And in case of a Swing (JavaFX) app observable lists can be very handy.
>
> Tom
>
>
>
> On 2012-10-28 08:42, Daniel Zwolenski wrote:
>
>> I stand by my comments but looks like a case of personal preference.
>>
>> Curious though, what do you use observable properties for on the server?
>> How are you leveraging them for an advantage?
>>
>>
>>
>> On 28/10/2012, at 6:29 PM, Tom Eugelink <tbee at tbee.org> wrote:
>>
>> As it happens I'm a long term user of JPA (Eclipselink), so I know a
>>> little bit about what happens beneath the surface.
>>>
>>> JPA postprocesses all the entities classes. During this postprocessing
>>> it mainly renames the instance variables and replaces them with
>>> placeholders. These placeholders then add a.o. lazy loading (only load the
>>> data when the value is accessed) and change monitoring (mark an entity as
>>> dirty when the variable is modified).
>>>
>>> When JFX properties would be used as JPA properties, what would need to
>>> happen is that the variable inside the property is postprocessed (assuming
>>> FIELD level postprocessing). But we don't want to / can't change a class
>>> that's inside the JRE. However, JPA postprocessing adds things that JFX
>>> properties actually already do, with their invalidation, etc. You probably
>>> could create classes (extending JFX Property) that are drop-in replacements
>>> for JFX's and hold all the required JPA logic that normally would be added
>>> using postprocessing. This would either remove the need for postprocessing
>>> for this part, or make postprocessing very simple. In any case it would
>>> still allow the power of JFX binding.
>>>
>>> I'm using JGoodies binding at the moment, which works flawlessly. Why
>>> would JFX listeners be different? In the end the placeholder detect changes
>>> to the variables, no matter how these changes came to be.
>>>
>>> JPA entities are not considered linked to the database table, they're
>>> just configured to store and retrieve from tables. That is what JPA's
>>> locking mechanism is for. Binding them would create a huge problem
>>> implementationwise, performancewise, and code maintainabilitywise.
>>> Discussing this would overflow the mailing list. To summarize: change
>>> conflicts are handled upon commit.
>>>
>>> JPA caching does nothing magical; a copy can be in the EM's cache or in
>>> the EMF's cache. This only is relevant when loading and persisting, not
>>> during usage. Things like equality and hash value are important and
>>> properties need to be included when determining those.
>>>
>>> Observable lists in the end are just lists. So a placeholder is placed
>>> in front and loads the actual contents once it is being accessed for the
>>> first time.
>>>
>>> Package names is easy. You could use fronting packages, but jigsaw
>>> probably will require the properties to move into a separate package, and
>>> get fronts in JFX packages and JPA packages for backwards compatibility /
>>> create specialized versions.
>>>
>>> I'm not seeing bears.
>>>
>>> Tom
>>>
>>>
>>>
>>> On 2012-10-28 00:15, Daniel Zwolenski wrote:
>>>
>>>> I totally agree with Tom Schindl. Jfx properties do not fit in the
>>>> current JPA model and no one would/should use them there. Properties might
>>>> be useful on the server side (maybe) but not in your JPA beans.
>>>>
>>>> Extending what Tom said, I think it is a huge anti-pattern to share
>>>> your server side beans on your client anyway. People should have DB-centric
>>>> JPA beans on the server and Screen-centric beans on the client. Lots of
>>>> reasons for this. I could go into great detail on this and different
>>>> patterns. It was to be the next topic for my zenjava blog before I stopped
>>>> using jfx, and showcasing such patterns was something I suggested the
>>>> "enterprise jfx focus group" would do but that didn't seem so popular an
>>>> idea so I'll take the hint and spare the list this.
>>>>
>>>> Just to add some more specifics on JPA beans having properties on them,
>>>> as well as what Tom said, I would add:
>>>>
>>>> Caching woes - JPA does lots of magical caching and properties and
>>>> listeners would massively confuse the cache engine, the GC and the
>>>> developers if anyone tried to actually use them on the server side. That's
>>>> before you start looking at transaction boundaries too.
>>>>
>>>> Misleading API - JPA beans are conceptually linked to a db table, does
>>>> adding a listener to a property mean I'll get a callback if someone changes
>>>> my table data (answer is definitely no on a distributed, sharded setup, but
>>>> API implies that it could).
>>>>
>>>> Collections - observable lists would need to be supported too. JPA does
>>>> magical things to collections (lazy loading, etc), fx collections don't fit
>>>> in there.
>>>>
>>>> Wrong package - these properties are in jfx packages which implies
>>>> client ui. Server guys won't want to go near them - psychology of this is
>>>> often overlooked. Plus when/if jigsaw and modularisation happens, you add
>>>> potential inter-dependencies that are odd and non-intuitive (eg my shared
>>>> hosting provider could well say "no jfx on this server jre cause it's ui
>>>> and we don't want people doing that here").
>>>>
>>>>
>>>>
>>>> On 28/10/2012, at 3:28 AM, Tom Schindl <tom.schindl at bestsolution.at>
>>>> wrote:
>>>>
>>>> Hi,
>>>>>
>>>>> I really like JavaFX properties but their concept really only makes
>>>>> sense on the client.
>>>>>
>>>>> Main points:
>>>>> * They waste memory
>>>>> * are not supported on all JVM (people tend to forget that javafx is
>>>>> not JSRed and only part of openjdk/oracle jdk).
>>>>>
>>>>>
>>>>> On memory:
>>>>> ----------
>>>>> We can talk about laziness as much as we want but when reading a bean
>>>>> from the database 95% of the fields are none null, hence lazy creation
>>>>> is a nightmare.
>>>>>
>>>>> In my opinion VM properties are very different to what we have in
>>>>> JavaFX.
>>>>>
>>>>>
>>>>> On standard:
>>>>> ------------
>>>>> As outlined and confirmed by Richard, Oracle does not guarantee that
>>>>> things work on all JVMs (e.g. j9) it might or might not work and can be
>>>>> broken any time.
>>>>>
>>>>> JavaFX will be JSRed by Java9 not sure if vendors are forced to
>>>>> implement the started. When you state other JSRed technologies should
>>>>> adapt to the JavaFX bean standard the they can before Java9.
>>>>>
>>>>>
>>>>> General statement:
>>>>> ------------------
>>>>> I'm not even sure why people have such a big problem with using a
>>>>> different object on the server (Plain POJO) and Java(FX)-Bean on the
>>>>> client, writing POJOs by hand is a boring and senseless task using some
>>>>> meta format or tool and generate the POJOs and JavaFX-Beans out of that
>>>>> is not rocket sience.
>>>>>
>>>>> Tom
>>>>>
>>>>> Am 27.10.12 16:29, schrieb Tom Eugelink:
>>>>>
>>>>>> About using JavaFX beans server side; can you explain why that would
>>>>>> be
>>>>>> a bad idea beside the fact that there isn't any support in frames like
>>>>>> JDBC?
>>>>>>
>>>>>> There has been a big demand from the community for real properties in
>>>>>> Java. Now JavaFX has become part of the standard JDK, I expect people
>>>>>> to
>>>>>> start using these properties in other area's as well. The binding
>>>>>> concept is rather powerful and once the concept sinks in... This then
>>>>>> would have consequences; some bindings no longer can be lazy, we need
>>>>>> bean level listeners, etc. But this can all be added quite easily.
>>>>>> Then
>>>>>> JDBC and JPA need to be enhanced to support them and we're pretty much
>>>>>> done.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> On 2012-10-27 15:55, Tom Schindl wrote:
>>>>>>
>>>>>>> If I remember correctly it had to do with listeners and how to manage
>>>>>>> that they are not leaked but I could be wrong.
>>>>>>>
>>>>>>> Anyways nobody guarantees that OpenJFX will run on other vendors
>>>>>>> JVMs,
>>>>>>> am I right? I generally think using JavaFX-Beans on the server side
>>>>>>> is a
>>>>>>> bad idea.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> Am 27.10.12 15:24, schrieb Richard Bair:
>>>>>>>
>>>>>>>> I cannot imagine what internal stuff Michael could be using or when
>>>>>>>> that was added.
>>>>>>>>
>>>>>>>> On Oct 26, 2012, at 7:42 AM, Tom Schindl
>>>>>>>> <tom.schindl at bestsolution.at> wrote:
>>>>>>>>
>>>>>>>> Not only the memory argument is import.
>>>>>>>>>
>>>>>>>>> What if a customer says i have to run on his j9-jvm?
>>>>>>>>>
>>>>>>>>> I can be wrong but IIRC Michael told me at JavaOne that the
>>>>>>>>> properties
>>>>>>>>> code is even using internal (sun....) stuff so even simply
>>>>>>>>> dropping in
>>>>>>>>> the jar to the j9 classpath is doomed to fail.
>>>>>>>>>
>>>>>>>>> And beside that using FX-Observables and e.g. JPA don't like each
>>>>>>>>> other
>>>>>>>>> i guess because of all those lazy list stuff, ... .
>>>>>>>>>
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> Am 22.10.12 19:23, schrieb Werner Lehmann:
>>>>>>>>>
>>>>>>>>>> Richard,
>>>>>>>>>>
>>>>>>>>>> On 22.10.2012 17:38, Richard Bair wrote:
>>>>>>>>>>
>>>>>>>>>>> MyObject obj = new MyObject();
>>>>>>>>>>> obj = BlackMagic.makeObservable(obj)**;
>>>>>>>>>>>
>>>>>>>>>> I'd like to see the implementation of BlackMagic ;-) (cglib
>>>>>>>>>> stuff?)
>>>>>>>>>>
>>>>>>>>>> However, the javafx beans package and collections and such are
>>>>>>>>>>> part
>>>>>>>>>>> of the "base" module -- ie: they could be separated from the
>>>>>>>>>>> rest of
>>>>>>>>>>> javafx and safely used on the server side or elsewhere. Why not
>>>>>>>>>>> just
>>>>>>>>>>> use properties and such on the server side definition of
>>>>>>>>>>> classes? Or
>>>>>>>>>>> are those classes being auto-generated and thus not taking
>>>>>>>>>>> observable
>>>>>>>>>>> properties into account?
>>>>>>>>>>>
>>>>>>>>>> Currently I want to avoid requiring customers to install the FX
>>>>>>>>>> runtime
>>>>>>>>>> serverside. That will be a moot point with JRE 7+. Which does not
>>>>>>>>>> help
>>>>>>>>>> the 6.x customers, especially if they are on WebLogic which is
>>>>>>>>>> usually
>>>>>>>>>> tied to a specific major version.
>>>>>>>>>>
>>>>>>>>>> Another aspect is the footprint regarding memory and bandwidth.
>>>>>>>>>> Obviously a StringProperty requires more bytes than a String.
>>>>>>>>>> This is
>>>>>>>>>> not an issue (usually) when I want to display a relatively short
>>>>>>>>>> list of
>>>>>>>>>> beans in the UI. It gets noticeable when the server suddenly
>>>>>>>>>> needs +X
>>>>>>>>>> megabytes, the instantion of objects needs +Y ms (also affects
>>>>>>>>>> deserialization), and sending them over the network takes +Z ms...
>>>>>>>>>>
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> B e s t S o l u t i o n . a t EDV Systemhaus
>>>>>>>>> GmbH
>>>>>>>>> ------------------------------**------------------------------**
>>>>>>>>> ------------
>>>>>>>>>
>>>>>>>>> tom schindl geschäftsführer/CEO
>>>>>>>>> ------------------------------**------------------------------**
>>>>>>>>> ------------
>>>>>>>>>
>>>>>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512
>>>>>>>>> 935833
>>>>>>>>> http://www.BestSolution.at phone ++43 512
>>>>>>>>> 935834
>>>>>>>>>
>>>>>>>> --
>>>>> B e s t S o l u t i o n . a t EDV Systemhaus
>>>>> GmbH
>>>>> ------------------------------**------------------------------**
>>>>> ------------
>>>>> tom schindl geschäftsführer/CEO
>>>>> ------------------------------**------------------------------**
>>>>> ------------
>>>>> eduard-bodem-gasse 5-7/1 A-6020 innsbruck fax ++43 512
>>>>> 935833
>>>>> http://www.BestSolution.at phone ++43 512
>>>>> 935834
>>>>>
>>>>
>
More information about the openjfx-dev
mailing list