JPA properties

Will Hoover java.whoover at
Tue Oct 30 05:28:21 PDT 2012

I can see both sides of the argument for and against shared use of EMs
across tiers. For me, the more fundamental issue is the need for a seamless
approach that allows binding across any number of POJOs and their
corresponding fields. I view the client as a container and should be treated
accordingly. It shouldn't be concerned with "how" we give it data, but
rather "what" data we give it. I understand the need for the bean properties
in JFX, but I also believe their existence is due to the lack of a formal
language-level observer apparatus on POJOs (rather than bytecode mangling or
pseudo property classes).

-----Original Message-----
From: openjfx-dev-bounces at
[mailto:openjfx-dev-bounces at] On Behalf Of Daniel Zwolenski
Sent: Sunday, October 28, 2012 7:44 AM
To: Tom Eugelink
Cc: openjfx-dev at
Subject: Re: JPA properties

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> 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> 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
>>> 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
>>>> On 28/10/2012, at 3:28 AM, Tom Schindl 
>>>> <tom.schindl 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> 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
>>>>>>>>> GmbH
>>>>>>>>> ------------------------------**------------------------------
>>>>>>>>> **
>>>>>>>>> ------------
>>>>>>>>> tom schindl                 geschäftsführer/CEO
>>>>>>>>> ------------------------------**------------------------------
>>>>>>>>> **
>>>>>>>>> ------------
>>>>>>>>> eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512
>>>>>>>>> 935833
>>>>>>>>>                      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
>>>>>                      phone    ++43 512
>>>>> 935834

More information about the openjfx-dev mailing list