Making JavaFX Development Faster

[Tom Schindl]

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