Remove boilerplate code in your JUnit tests with parameterized tests.

Learn how to use the Bean Validation outside of your Java EE container.

Learn unit testing concepts, JUnit constructs, how to write good assertions, JUnit 4 annotations, and JUnit test suites.

Using JMX you can monitor you Java EE servers for key metrics.

Learn how you can use partially applied functions in Java 8

How to use Spring Integration to keep domain and integration concerns separate and simple for many Spring-based applications.

How to put Spring, Spring Boot, and Spring Cloud together to create a microservice.

You can start using Apache Camel routes in Java EE components by integrating Camel with the WildFly App Server, using the WildFly-Camel Subsystem.

Take your first steps in using JUnit to unit test your Java code with the help of tools like Maven, a build tool, and IntelliJ IDEA, a popular IDE.

H2 as a memory database for Spring-based applications is lightweight, easy to use, and emulates other RDBMS with the help of JPA and Hibernate.

Using Permutations, you can try all combinations of an input set.

Yeah, they don't really exist, but we can use polymorphism, method overloading and default methods instead to make it a bit more convenient to use our APIs. As an example, here's an event bus implementation where I can register event handlers with an optional header parameter. Bus bus = new Bus(); bus.register(event -> System.out.println("I gots an event")); bus.register((event,header) -> System.out.println("I gots an event w/ header")); Here are the dirty details on how you can do this (and - when dispatching - events, use default methods to avoid type coercion.

I’ve built a small example of running a standalone Java application that both serves static HTML, JavaScript, CSS content, and also publishes a REST web service.

Casting an instance to a type reeks of bad design. Still, there are situations where there is no other choice. The ability to do this has always been part of Java.

Mockito-Java8 is a set of Mockito add-ons leveraging Java 8 and lambda expressions to make mocking with Mockito even more compact. At the beginning of 2015 I gave my flash talk Java 8 brings power to testing! at GeeCON TDD 2015 and DevConf.cz 2015. In my speech using 4 examples I showed how Java 8 – namely lambda expressions – can simplify testing tools and testing in general. One of those tools was Mokcito. To not let my PoC code die on slides and to make it simply available for others I have released a small project with two, useful in specified case, Java 8 add-ons for Mockito. Quick introduction As a prerequisite, let's assume we have the following data structure: @Immutable class ShipSearchCriteria { int minimumRange; int numberOfPhasers; } and a class we want to stub/mock: public class TacticalStation { public int findNumberOfShipsInRangeByCriteria( ShipSearchCriteria searchCriteria) { ... } } The library provides two add-ons: Lambda matcher - allows to define matcher logic within a lambda expression. given(ts.findNumberOfShipsInRangeByCriteria( argLambda(sc -> sc.getMinimumRange() > 1000))).willReturn(4); Argument Captor - Java 8 edition - allows to use `ArgumentCaptor` in a one line (here with AssertJ): verify(ts).findNumberOfShipsInRangeByCriteria( assertArg(sc -> assertThat(sc.getMinimumRange()).isLessThan(2000))); Lambda matcher With a help of the static method argLambda a lambda matcher instance is created which can be used to define matcher logic within a lambda expression (here for stubbing). It could be especially useful when working with complex classes pass as an argument. @Test public void shouldAllowToUseLambdaInStubbing() { //given given(ts.findNumberOfShipsInRangeByCriteria( argLambda(sc -> sc.getMinimumRange() > 1000))).willReturn(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } In comparison the same logic implemented with a custom Answer in Java 7: @Test public void stubbingWithCustomAsnwerShouldBeLonger() { //old way //given given(ts.findNumberOfShipsInRangeByCriteria(any())).willAnswer(new Answer() { @Override public Integer answer(InvocationOnMock invocation) throws Throwable { Object[] args = invocation.getArguments(); ShipSearchCriteria criteria = (ShipSearchCriteria) args[0]; if (criteria.getMinimumRange() > 1000) { return 4; } else { return 0; } } }); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } Even Java 8 and less readable constructions don't help too much: @Test public void stubbingWithCustomAsnwerShouldBeLongerEvenAsLambda() { //old way //given given(ts.findNumberOfShipsInRangeByCriteria(any())).willAnswer(invocation -> { ShipSearchCriteria criteria = (ShipSearchCriteria) invocation.getArguments()[0]; return criteria.getMinimumRange() > 1000 ? 4 : 0; }); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(1500, 2))).isEqualTo(4); //expect assertThat(ts.findNumberOfShipsInRangeByCriteria( new ShipSearchCriteria(700, 2))).isEqualTo(0); } Argument Captor - Java 8 edition A static method assertArg creates an argument matcher which implementation internally uses ArgumentMatcher with an assertion provided in a lambda expression. The example below uses AssertJ to provide meaningful error message, but any assertions (like native from TestNG or JUnit) could be used (if really needed). This allows to have inlined ArgumentCaptor: @Test public void shouldAllowToUseAssertionInLambda() { //when ts.findNumberOfShipsInRangeByCriteria(searchCriteria); //then verify(ts).findNumberOfShipsInRangeByCriteria( assertArg(sc -> assertThat(sc.getMinimumRange()).isLessThan(2000))); } In comparison to 3 lines in the classic way: @Test public void shouldAllowToUseArgumentCaptorInClassicWay() { //old way //when ts.findNumberOfShipsInRangeByCriteria(searchCriteria); //then ArgumentCaptor captor = ArgumentCaptor.forClass(ShipSearchCriteria.class); verify(ts).findNumberOfShipsInRangeByCriteria(captor.capture()); assertThat(captor.getValue().getMinimumRange()).isLessThan(2000); } Summary The presented add-ons were created as PoC for my conference speech, but should be fully functional and potentially useful in the specific cases. To use it in your project it is enough to use Mockito 1.10.x or 2.0.x-beta, add `mockito-java8` as a dependency and of course compile your project with Java 8+. More details are available on the project webpage: https://github.com/szpak/mockito-java8

Collections in JavaFX are defined by the javafx.collections package, which consists of the following interfaces and classes: Interfaces: ObservableList: A list that enables listeners to track changes when they occur ListChangeListener: An interface that receives notifications of changes to an ObservableList ObservableMap: A map that enables observers to track changes when they occur MapChangeListener: An interface that receives notifications of changes to an ObservableMap Classes: FXCollections: A utility class that consists of static methods that are one-to-one copies of java.util.Collections methods ListChangeListener.Change: Represents a change made to an ObservableList MapChangeListener.Change: Represents a change made to an ObservableMap Example of ObservableList Here a standard List is first created. It is then wrapped with an ObservableList. A ListChangeListener is then registered, and will receive notification whenever a change is made on the ObservableList : packageorg.attune.collection; importjava.util.List; importjava.util.ArrayList; importjavafx.collections.ObservableList; importjavafx.collections.ListChangeListener; importjavafx.collections.FXCollections; public class ObservableListDemo { public static void main(String[] args) { List list = new ArrayList(); ObservableListobservableList = FXCollections.observableList(list); observableList.addListener(new ListChangeListener() { @Override public void onChanged(ListChangeListener.Change change) { System.out.println("Detected a change! "); while (change.next()) { System.out.println("Was added? " + change.wasAdded()); System.out.println("Was removed? " + change.wasRemoved()); } } }); observableList.add("a : item one"); System.out.println("Size: " + observableList.size()+observableList.toString()); list.add("d : item two"); System.out.println("Size: " + observableList.size()+observableList.toString()); observableList.add("f : item Three"); System.out.println("Size: " + observableList.size()+observableList.toString()); list.add("b : item four"); System.out.println("Size: " + observableList.size()+observableList.toString()); observableList.remove(1); System.out.println("Size: " + observableList.size()+observableList.toString()); observableList.sort(null); System.out.println("Size: " + observableList.size()+observableList.toString()); observableList.set(2, "c : item five"); System.out.println("Size: " + observableList.size()+observableList.toString()); } } Here is output of above program: Detected a change! Was added? true Was removed? false Size: 1[a : item one] Size: 2[a : item one, d : item two] Detected a change! Was added? true Was removed? false Size: 3[a : item one, d : item two, f : item Three] Size: 4[a : item one, d : item two, f : item Three, b : item four] Detected a change! Was added? false Was removed? true Size: 3[a : item one, f : item Three, b : item four] Detected a change! Was added? false Was removed? false Size: 3[a : item one, b : item four, f : item Three] Detected a change! Was added? true Was removed? true Size: 3[a : item one, b : item four, c : item five] Example of ObservableMap package org.attune.collection; import java.util.Map; import java.util.HashMap; import javafx.collections.ObservableMap; import javafx.collections.MapChangeListener; import javafx.collections.FXCollections; public class ObservableMapDemo { public static void main(String[] args) { Map map = new HashMap(); ObservableMap observableMap = FXCollections.observableMap(map); observableMap.addListener(new MapChangeListener() { @Override public void onChanged(MapChangeListener.Change change) { System.out.println("Detected a change! "); } }); // Changes to the observableMap WILL be reported. observableMap.put("key 1","value 1"); System.out.println("Size: "+observableMap.size() + observableMap.toString()); // Changes to the underlying map will NOT be reported. map.put("key 2","value 2"); System.out.println("Size: "+observableMap.size()+ observableMap.toString()); // Changes to the observableMap WILL be reported. observableMap.remove("key 1"); System.out.println("Size: "+observableMap.size() + observableMap.toString()); } } Here is the output: Detected a change! Size: 1{key 1=value 1} Size: 2{key 2=value 2, key 1=value 1} Detected a change! Size: 1{key 2=value 2} Stay tuned for More Educational Content Attune World Wide

Unit Testing mandates to test the unit in isolation. In order to achieve that, the general consensus is to design our classes in a decoupled way using DI. In this paradigm, whether using a framework or not, whether using compile-time or runtime compilation, object instantiation is the responsibility of dedicated factories. In particular, this means the new keyword should be used only in those factories. Sometimes, however, having a dedicated factory just doesn’t fit. This is the case when injecting an narrow-scope instance into a wider scope instance. A use-case I stumbled upon recently concerns event bus, code like this one: public class Sample { private EventBus eventBus; public Sample(EventBus eventBus) { this.eventBus = eventBus; } public void done() { Result result = computeResult() eventBus.post(new DoneEvent(result)); } private Result computeResult() { ... } } With a runtime DI framework – such as the Spring framework, and if the DoneEvent had no argument, this could be changed to a lookup method pattern. public void done() { eventBus.post(getDoneEvent()); } public abstract DoneEvent getDoneEvent(); Unfortunately, the argument just prevents us to use this nifty trick. And it cannot be done with runtime injection anyway. It doesn’t mean the done() method shouldn’t be tested, though. The problem is not only how to assert that when the method is called, a new DoneEvent is posted in the bus, but also check the wrapped result. Experienced software engineers probably know about the Mockito.any(Class) method. This could be used like this: public void doneShouldPostDoneEvent() { EventBus eventBus = Mockito.mock(EventBus.class); Sample sample = new Sample(eventBus); sample.done(); Mockito.verify(eventBus).post(Mockito.any(DoneEvent.class)); } In this case, we make sure an event of the right kind has been posted to the queue, but we are not sure what the result was. And if the result cannot be asserted, the confidence in the code decreases. Mockito to the rescue. Mockito provides captures, that act like placeholders for parameters. The above code can be changed like this: public void doneShouldPostDoneEventWithExpectedResult() { ArgumentCaptor captor = ArgumentCaptor.forClass(DoneEvent.class); EventBus eventBus = Mockito.mock(EventBus.class); Sample sample = new Sample(eventBus); sample.done(); Mockito.verify(eventBus).post(captor.capture()); DoneEvent event = captor.getCapture(); assertThat(event.getResult(), is(expectedResult)); } At line 2, we create a new ArgumentCaptor. At line 6, We replace any() usage with captor.capture() and the trick is done. The result is then captured by Mockito and available through captor.getCapture() at line 7. The final line – using Hamcrest, makes sure the result is the expected one.

When you first learn to develop you see overly broad statements about different features to be bad, for design, performance, clarity, maintainability, it feels like a hack, or they just don't like it. In this post, I look at some of the feature people like to hate and why I think that used correctly, they should be a force for good. Features are not as yes/no, good/bad as many like to believe. Checked Exceptions I am often surprised at the degree that developers don't like to think about error handling. New developers don't even like to read error messages. It's hard work, and they complain the application crashed, "it's not working". They have no idea why the exception was thrown when often the error message and stack dump tell them exactly what went wrong if they could only see the clues. When I write out stack traces for tracing purposes, many just see the log shaped like a crash when there was no error. Reading error messages is a skill and at first it can be overwhelming. Similarly, handling exceptions in a useful manner is too often avoided. I have no idea what to do with this exception, I would rather either log the exception and pretend it didn't happen or just blow up and let the operations people or to the GUI user, who have the least ability to deal the error. Many experienced developers hate checked exceptions as a result. However, the more I hear this, the more I am glad Java has checked exception as I am convinced they really will find it too easy ignore the exceptions and just let the application die if they are not annoyed by them. Checked exceptions can be overused of course. The question should be when throwing a checked exception; do I want to annoy the developer calling the code by forcing them to think a little bit about error handling? If the answer is yes, throw a checked exception. Was Thread.currentThread().stop(e) unsafe? The method Thread.stop(Throwable) was unsafe when it could cause another thread to trigger an exception in a random section of code. This could be a checked exception in a portion of code which didn't expect it, or throw an exception which is caught in some portions of the thread but not others leaving you with no idea what it would do. However, the main reason it was unsafe is that it could leave atomic operations in as synchronized of locked section of code in an inconsistent state corrupting the memory in subtle and untestable ways. To add to the confusion, the stack trace of the Throwable didn't match the stack trace of the thread where the exception was actually thrown. But what about Thread.currentThread().stop(e)? This triggers the current thread to throw an exception on the current line. This is no worse than just using throw exception you are performing an operation the compiler can't check. These are only two worthless features but if you want to read full and detail then check Geek On Java - Hub for Android and Java

[This article was written by Juergen Hoeller.] Spring is well-known to actively support the latest versions of common open source projects out there, e.g. Hibernate and Jackson but also common server engines such as Tomcat and Jetty. We usually do this in a backwards-compatible fashion, supporting older versions at the same time - either through reflective adaptation or through separate support packages. This allows for applications to selectively decide about upgrades, e.g. upgrading to the latest Spring and Jackson versions while preserving an existing Hibernate 3 investment. With the upcoming Spring Framework 4.2, we are taking the opportunity to support quite a list of new open source project versions, including some rather major ones: Hibernate ORM 5.0 Hibernate Validator 5.2 Undertow 1.2 / WildFly 9 Jackson 2.6 Jetty 9.3 Reactor 2.0 SockJS 1.0 final Moneta 1.0 (the JSR-354 Money & Currency reference implementation) While early support for the above is shipping in the Spring Framework 4.2 RCs already, the ultimate point that we’re working towards is of course 4.2 GA - scheduled for July 15th. At this point, we’re eagerly waiting for Hibernate ORM 5.0 and Hibernate Validator 5.2 to GA (both of them are currently at RC1), as well as WildFly 9.0 (currently at RC2) and Jackson 2.6 (currently at RC3). Tight timing… By our own 4.2 GA on July 15th, we’ll keep supporting the latest release candidates, rolling any remaining GA support into our 4.2.1 if necessary. If you’d like to give some of those current release candidates a try with Spring, let us know how it goes. Now is a perfect time for such feedback towards Spring Framework 4.2 GA! P.S.: Note that you may of course keep using e.g. Hibernate ORM 3.6+ and Hibernate Validator 4.3+ even with Spring Framework 4.2. A migration to Hibernate ORM 5.0 in particular is likely to affect quite a bit of your setup, so we only recommend it in a major revision of your application, whereas Spring Framework 4.2 itself is designed as a straightforward upgrade path with no impact on existing code and therefore immediately recommended to all users.

The standard usage of JavaFX TableView with currently available set of cell controls, with all its indisputable merits, fails to meet a fairly important requirement, which usually arises when editable fields are mutually dependent. Generally it is easy enough to change values of all dependent fields when value of some field had been changed. The real problem emerges when a cell control, which is connected with a single data field (property), should become editable or not editable (having a fixed value) depending on values of some other fields (properties) of the same record (row data object). Besides, to spare user some useless clicks and confusion, it is important to make appearance of the cell reflect at least two conditions: editable/not editable and within/outside of the selected row. To make it work, there is no need to subclass anything but table-cell controls. While it is possible to subclass TableCell and recreate all the specific cell controls, it is much easier to subclass each particular cell control, although it does lead to some minor duplication of code. To insure that all our custom cells refer to the same style definitions in a CSS stylesheet, let's share style constants in an interface: public interface IDeCell { public static final String CLASS_DE_CELL = "de-cell"; public static final String PSEUDO_CLASS_NOT_EDITABLE = "not-editable"; public static final String PSEUDO_CLASS_ROW_SELECTED = "row-selected"; } Prefix "de" stands for Dynamic Editability. We are going to prefix our custom cell extensions with "De" and refer to such cells as "de-cells". Here is source code of custom TextFieldTableCell extension: public class DeTextFieldTableCell extends TextFieldTableCell implements IDeCell { private static final PseudoClass NOT_EDITABLE_PSEUDO_CLASS = PseudoClass.getPseudoClass(PSEUDO_CLASS_NOT_EDITABLE); private static final PseudoClass ROW_SELECTED_PSEUDO_CLASS = PseudoClass.getPseudoClass(PSEUDO_CLASS_ROW_SELECTED); public BooleanProperty notEditableProperty() { return notEditable; } public final boolean isNotEditable() { return notEditableProperty().get(); } private final BooleanProperty notEditable = new SimpleBooleanProperty(this, PSEUDO_CLASS_NOT_EDITABLE, false) { @Override protected void invalidated() { pseudoClassStateChanged(NOT_EDITABLE_PSEUDO_CLASS, get()); } }; public final BooleanProperty rowSelectedProperty() { return rowSelected; } public final boolean isRowSelected() { return rowSelectedProperty().get(); } private final BooleanProperty rowSelected = new SimpleBooleanProperty(this, PSEUDO_CLASS_ROW_SELECTED, false) { @Override protected void invalidated() { pseudoClassStateChanged(ROW_SELECTED_PSEUDO_CLASS, get()); } }; public SimpleObjectProperty recordProperty() { return record; } private SimpleObjectProperty record = new SimpleObjectProperty<>(); public DeTextFieldTableCell(StringConverter converter) { super(converter); getStyleClass().add(CLASS_DE_CELL); notEditable.bind(editableProperty().not()); tableRowProperty().addListener((ov, vOld, vNew)-> { record.unbind(); rowSelected.unbind(); if (vNew != null) { record.bind(vNew.itemProperty()); rowSelectedProperty().bind(vNew.selectedProperty()); } }); } } DeTextFieldTableCell and all other de-cell controls share identical lines of code which define Boolean properties "rowSelected" and "notEditable" and respective custom CSS pseudo-classes "row-selected" and "not-editable". Additionally, de-cells expose row object (record) with "record" property. Code, which makes editability and appearance of a cell depend on values of one or more properties of the "record" has to look like this: cell.recordProperty().addListener((ov, r0, r) -> { cell.editableProperty().unbind(); if (r != null) { cell.editableProperty().bind(r.someProperty().and(r.otherProperty())); } }); Here is sample CSS for de-cells: .de-cell:filled:not-editable { -fx-background-color: #cccccc; -fx-text-fill: #0000ff; -fx-border-width: 1px 0px 0px 1px; -fx-border-color: #eeeeee } .de-cell:filled:row-selected { -fx-background-color: skyblue; -fx-text-fill: black; -fx-border-width: 1px 0px 0px 1px; -fx-border-color: #eeeeee } .de-cell:filled:not-editable:row-selected { -fx-background-color: #999999; -fx-text-fill: #0000ff } The example below is a taken (with some simplification) from the existing working application. There is a system, which allows customers to buy online prints and file downloads. All general, non-specific files, which are accessible by general customers, have preassigned General Prices: price of 1 printed copy for printable and download price for not printable ones. Besides, there are special, tailor-made files, which are not accessible by general customers and don't have General Prices. A customer can fetch products himself (with General Price only), or some products can be pushed to him by a sales manager - with General Price or (relatively reduced) Special Price. In the first case number of the printed copies to be chosen by the customer, whereas in the last case number of printed copies has to be limited by the sales manager. In case of special, tailor-made files Special Price has to be assigned. Number of copies (quantity) for the file download is always equal 1. At some point a sales manager collects all products (both general and tailor-made) to be pushed to a customer and has to edit collected entries. He/She can change any general price to a special one, allow download of a printable product, edit Special prices and printed copies (quantities). There are following dependencies: 1. General/Special choice is enabled for the general products only. 2. Print/Download choice is enabled for printable products when Special Price is selected. 3. Price is editable when Special Price is selected, otherwise it has to be equal to preassigned General Price. 4. Quantity is editable when Special Price and Print Service are selected. When Download selected quantity is fixed and equals 1, when General and Print selected quantity is null (to be chosen by customer). For example, for a sample product "*A: General Print" the only editable dynamic field is "Price Type". If a user changes Price Type to Special then Service Type, Item Price and Quantity become editable. If a user changes Service Type to Download then Quantity become not editable (and set to 1). Here is source code for data object Entry: public class Entry { private final IntegerProperty entryId = new SimpleIntegerProperty(); private final StringProperty name = new SimpleStringProperty(); private final BooleanProperty printable = new SimpleBooleanProperty(); private final BooleanProperty useGeneralPrice = new SimpleBooleanProperty(); private final BooleanProperty usePrintService = new SimpleBooleanProperty(); private final ObjectProperty generalPrice = new SimpleObjectProperty<>(); private final ObjectProperty price = new SimpleObjectProperty<>(); private final ObjectProperty quantity = new SimpleObjectProperty<>(); private final ObjectProperty totalPrice = new SimpleObjectProperty<>(); public IntegerProperty entryIdProperty() { return entryId; } public StringProperty nameProperty() { return name; } public BooleanProperty printableProperty() { return printable; } public BooleanProperty useGeneralPriceProperty() { return useGeneralPrice; } public BooleanProperty usePrintServiceProperty() { return usePrintService; } public ObjectProperty generalPriceProperty() { return generalPrice; } public ObjectProperty priceProperty() { return price; } public ObjectProperty quantityProperty() { return quantity; } public ObjectProperty totalPriceProperty() { return totalPrice; } public Entry(int aEntryId, String aName, BigDecimal aGeneralPrice, boolean aPrintable) { entryId.set(aEntryId); name.set(aName); printable.set(aPrintable); useGeneralPrice.set(aGeneralPrice != null); usePrintService.set(aPrintable); generalPrice.set(aGeneralPrice); price.set(aGeneralPrice); quantity.set((aPrintable) ? null : 1); totalPrice.bind(new ObjectBinding() { { super.bind(price, quantity); } @Override protected Number computeValue() { return (price.get() == null || quantity.get() == null) ? null : price.get().doubleValue()*quantity.get(); } }); } } Here is an excerpt from the sample app - creation of table columns with de-cells: TableColumn priceTypeCol = new TableColumn<>("Price Type"); priceTypeCol.setPrefWidth(60); priceTypeCol.setCellValueFactory(new PropertyValueFactory<>("useGeneralPrice")); priceTypeCol.setCellFactory((tableColumn) -> { DeComboBoxTableCell cell = new DeComboBoxTableCell<>( new ABooleanConverter(PRICE_TYPES[0], PRICE_TYPES[1]), true, false); cell.recordProperty().addListener((ov, vOld, vNew) -> { cell.editableProperty().unbind(); if (vNew != null) cell.editableProperty().bind(vNew.generalPriceProperty().isNotNull()); }); return cell; }); priceTypeCol.setOnEditCommit((ev) -> { Entry entry = ev.getRowValue(); Boolean value = ev.getNewValue(); entry.useGeneralPriceProperty().set(value); if (value) { entry.priceProperty().set(entry.generalPriceProperty().get()); entry.usePrintServiceProperty().set(entry.printableProperty().get()); } entry.quantityProperty().set( (value && entry.usePrintServiceProperty().get()) ? null : 1); }); //============================================================== TableColumn serviceTypeCol = new TableColumn<>("Service Type"); serviceTypeCol.setPrefWidth(60); serviceTypeCol.setCellValueFactory(new PropertyValueFactory<>("usePrintService")); serviceTypeCol.setCellFactory((tableColumn) -> { DeComboBoxTableCell cell = new DeComboBoxTableCell<>( new ABooleanConverter(SERVICE_TYPES[0], SERVICE_TYPES[1]), true, false); cell.recordProperty().addListener((ov, vOld, vNew) -> { cell.editableProperty().unbind(); if (vNew != null) { cell.editableProperty().bind(vNew.useGeneralPriceProperty().not() .and(vNew.printableProperty())); } }); return cell; }); serviceTypeCol.setOnEditCommit((ev) -> { Entry entry = ev.getRowValue(); Boolean value = ev.getNewValue(); entry.usePrintServiceProperty().set(value); entry.quantityProperty().set(1); }); //============================================================== TableColumn priceCol = new TableColumn<>("Item Price"); priceCol.setPrefWidth(50); priceCol.setCellValueFactory(new PropertyValueFactory<>("price")); priceCol.setCellFactory((tableColumn) -> { DeTextFieldTableCell cell = new DeTextFieldTableCell<>( new AMoneyConverter()); cell.setAlignment(Pos.CENTER_RIGHT); cell.recordProperty().addListener((ov, vOld, vNew) -> { cell.editableProperty().unbind(); if (vNew != null) cell.editableProperty().bind(vNew.useGeneralPriceProperty().not()); }); return cell; }); priceCol.setOnEditCommit((ev) -> { ev.getRowValue().priceProperty().set(ev.getNewValue()); }); //============================================================== TableColumn quantityCol = new TableColumn<>("Quantity"); quantityCol.setPrefWidth(40); quantityCol.setCellValueFactory(new PropertyValueFactory<>("quantity")); quantityCol.setCellFactory((tableColumn) -> { DeTextFieldTableCell cell = new DeTextFieldTableCell<>( new IntegerStringConverter()); cell.setAlignment(Pos.CENTER); cell.recordProperty().addListener((ov, vOld, vNew) -> { cell.editableProperty().unbind(); if (vNew != null) { cell.editableProperty().bind(vNew.useGeneralPriceProperty().not() .and(vNew.usePrintServiceProperty())); } }); return cell; }); priceCol.setOnEditCommit((ev) -> { ev.getRowValue().priceProperty().set(ev.getNewValue()); }); //============================================================== TableColumn totalPriceCol = new TableColumn<>("Total Price"); totalPriceCol.setPrefWidth(50); totalPriceCol.setCellValueFactory(new PropertyValueFactory<>("totalPrice")); totalPriceCol.setCellFactory((tableColumn) -> { DeTextFieldTableCell cell = new DeTextFieldTableCell<>( new AMoneyConverter()); cell.setAlignment(Pos.CENTER_RIGHT); cell.setEditable(false); return cell; }); totalPriceCol.setEditable(false); --