posts/2009/javafx-lets-clarify-public-read-and-public-init/index

[JonathanGiles]

JavaFX: Let's clarify public-read and public-init

https://jonathangiles.net/posts/2009/javafx-lets-clarify-public-read-and-public-init/

[JonathanGiles]

Auto-imported comment, original author: codecraig Comment posted on: June 27, 2009

I wonder what the design decision was by the JavaFX people to do this...any ideas?

[JonathanGiles]

Auto-imported comment, original author: Richard Bair Comment posted on: June 28, 2009

We went through many different iterations and ideas. One day Robert Field and Brian Goetz whiteboarded all the different usage scenarios and found that pretty well all the different use cases we had could be boiled down to normal access modifiers and these two new ones.

From an API perspective, what we needed was the ability to make variables "read only" to the world, but allow us ourselves (the API developer) to update the variable. This is the equivalent of:

public String getFoo() { ... } private void setFoo(String s) { ... }

But with the option of specifying a different value than "private" for the setter. So:

public-read protected foo:String

is

public String getFoo() { ... } protected void setFoo() { ... }

One use case that we didn't expose is the write-only use case:

private String getFoo() { ... } public void setFoo(String s) { ... }

Seemed of dubious usage.

public-init has a very specific usage in JavaFX. Because we don't have constructors, we needed some way to allow initialization of variables but thereafter not allow them to be changed. This is important for immutable classes for example. So that's what we got public-init for.

[JonathanGiles]

Auto-imported comment, original author: codecraig Comment posted on: June 28, 2009

Ah, well if there are no constructors then I guess you need something....so I guess I wonder, why weren't constructors allowed/provided?

[JonathanGiles]

Auto-imported comment, original author: Jonathan Comment posted on: June 28, 2009

Just a different approach I guess. Through public-init variable declarations and init {..} and postinit {...} blocks you get effectively the same thing as you do with a constructor.

Some might say it's change for the sake of change, others will argue that it is a simpler approach. I think what is missing in general is a mapping for Java developers to understand how they move to JavaFX. Most things are obvious, but areas such as this result in confusion.

I'm trying to blog about things which don't have an obvious mapping from the Java world. If you have anything you'd like me to try and blog about, let me know.

btw, thanks to Richard for such a good reply above. It's much appreciated and it's great to see you sharing your knowledge from your work on JavaFX.

[JonathanGiles]

Auto-imported comment, original author: Gooder Code Comment posted on: September 14, 2009

<strong>Sticky Note, A JavaFX Tutorial...</strong>

JavaFX is Sun’s latest attempt at making an RIA friendly development technology. It’s aim is to compete with tools such as Adobe Flash/Flex/Air, and Silverlight. I am not going to do a comparison of these. Instead, I will focus on my first JavaF......

[JonathanGiles]

Auto-imported comment, original author: Srivis Comment posted on: December 23, 2009

Poor naming convention used here. It is very confusing. Naming should be self explanatory. And it should not be hidden. Here in this case write access is hidden.

package public-read

Common sense interpretation tells me that the only package has read access. Unless you remember the write access.

package public-init

This one I can interpret as it has only package level public-init access.

package-write public-read is more meaning full than "package public-read"

package-write public-init.