JPA properties

Sun Oct 28 01:54:05 PDT 2012

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