JPA properties
Will Hoover
java.whoover at gmail.com
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 openjdk.java.net
[mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Daniel Zwolenski
Sent: Sunday, October 28, 2012 7:44 AM
To: Tom Eugelink
Cc: openjfx-dev at openjdk.java.net
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 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