Drombler FX: Version 1.0 released

I've recently released the version v1.0 of Drombler FX - the modular application framework for JavaFX.

With this release I changed the version policy. I'm using now the major version part as well to make it easier to distinguish between major requirement changes such as the Java version:

• v1.x: Java SE 8 and JavaFX 8 based
• v2.x (future): Java SE 11 and JavaFX 11 based (likely)

The released JARs contain the Automatic-Module-Name Manifest entry to make the transition to Java SE 11 smoother.

For this v1.0 release I've added Javadoc to all published classes and members of  Drombler FX, Drombler ACP (except the generated JAXB classes) and Drombler Commons. 

There's now also a new Extensions tutorial trail.

Some APIs were fixed and some clean-ups were added as well.

Because some code has been moved, please note that some of the packages and Maven dependencies changed, too.

Please note especially, that localized texts are now expected in a separate properties file in the same package and with the same name as the annotated classes by default, and not in the package Bundle.properties file anymore (this can be configured per annotated class, though).
This makes it easier to move annotated classes to other packages and to see which texts are still in use.

With this v1.0 release out I will now start the work to migrate Drombler FX to Java SE 11 and JavaFX 11.

Additional Information

Projects like this one need to be build by a community working together to be really successful. There are several ways how you can contribute to this project. Contributions are highly welcome! See the "How to Contribute"-page for more information.

You can find the complete list of fixed issues here: https://github.com/Drombler/drombler-fx/issues?q=milestone%3A1.0


There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.


The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
  

Name	Modules (incl. Maven Coordinates)	Javadoc	Description
Drombler FX	Modules	Javadoc	Drombler FX, the modular application framework for JavaFX based on: OSGi Maven (POM-first) a declarative programming model Drombler ACP  Drombler Commons.
Drombler ACP	Modules	Javadoc	Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on: OSGi Maven (POM-first) a declarative programming model Drombler Commons.
Drombler Commons	Modules	Javadoc	Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment.

If you find issues or have enhancement requests, you can file a ticket here: https://github.com/Drombler/drombler-fx/issues.

 

Why apps should not render identity provider web sites in-app

Nowadays there are several public identity providers (IdP) such as Google accounts, Facebook accounts, GitHub accounts or SwissId accounts, just to name a few.

More and more mobile apps are starting to accept one or more of these IdPs as a replacement or as an addition to app specific user accounts to authenticate their users.

A common protocol to accomplish this is the OAuth 2.0 / OpenId Connect 1.0 protocol. In simple terms, here is how this protocol works:

1. The app or web site, which needs to authenticate a user, provides a button/ link to the web site of the IdP and adds a redirect link to the request.
2. When the user clicks the button/ link, the web site of the IdP gets opened.
3. As the users know and trust the IdP, they will enter their user names and passwords on that site. The original app will never see their passwords.
4. On completion of the IdP process, (simplified) the IdP will send a token to the redirect link the original app/ web site passed as parameter to the authentication request link.
5. The app / web site can then use this token to e.g. check the rights (roles) of the user (authorization).

Now, unfortunately, there are several apps which open the IdP web sites (step 2) "in-app", using a web view like component to render the IdP web site directly inside their apps (mostly for user experience reasons, I guess, so the user doesn't have to leave their app).

While this technically works, there is now no way for the user at step 3 to tell if the request for authentication is genuine or if this is a phishing attack by the app. There is also no way for the user to tell, if a developer wanted to do something "clever", which accidentally compromises the sensitive password. It breaks the OAuth 2.0 / OpenId Connect 1.0 concept that the original app will never see the users' passwords.

It doesn't help that the rendered web site shows the correct name of the IdP and it doesn't help either to show the URL e.g. at the top the app, as this is what a phishing app would do, too, wouldn't it?

As long as the request for authentication is processed in the original app, the user cannot tell if the request is genuine.

So by trying to increase the user experience by using an in-app web view component, you take away any possibilty for the user to check who actually sees the entered password.

Bottom line:

Dear app developers: please, never use an in-app web view component for authentication requests to third party IdPs. Use the browser or the IdP app instead, so the user has a chance to check the genuineness of the request.


There are already many companies and organizations who try to sensibilize users how they can detect phishing attacks, and checking the URL in the browser is one of the most effective detection mechanisms.

So please don't dilute these campaigns by excluding options for the users to perform these checks.

I think especially apps from the big companies should set a good example here, which at the time of writing, unfortunately, is not always the case.

And I guess it also would be good if review processes (e.g. such as the one from Apple to accept an application for their app store) would check that these kind of authentication don't take place "in-app".

News from the Software Smithy: Version 2.0 released

SoftSmithy news: after the release v1.1.1 last year (I didn't blog about it), I've recently released the version v2.0 of the SoftSmithy Utility Library and the SoftSmithy Development Utility Library.

As announced in the blog post about the release v1.0, v2.0 is still based on Java SE 8, but requires JUnit 5 when working with the JUnit helper classes.

This release also introduces an intitial version of the new Context Property Framework, which allows to access properties in a type-safe way accross mulitple map-like contexts.

The newly added ThreadLocalStorage allows to store properties in a ThreadLocal storage and can be used together with the new Context Property Framework.

// given the following foo property with name "foo" and type "Foo". public static final ContextProperty<Foo> FOO_PROPERTY = new ContextProperty<>("foo", Foo.class); [...] // and given some map-like contexts like Map<String, Object> someContextMap = ...; HttpServletRequest httpServletRequest = ...; // Java EE / Spring MVC WebTarget someWebTarget = ...; // JAX-RS WebTarget ClientRequestContext someClientRequestContext = ... ; // JAX-RS ClientRequestContext // ThreadLocalStorage // instead of the following read operations: Foo foo = (Foo) someContextMap.get("foo"); // or Foo foo = (Foo) httpServletRequest.getAttribute("foo"); // or Foo foo = (Foo) someClientRequestContext.getProperty("foo"); // or Foo foo = (Foo) ThreadLocalStorage.getPropertyValue("foo"); // with the Context Property Framework you can now access the properties without duplicating the name and type (casting): Foo foo = FOO_PROPERTY.getValue(someContextMap::get); // or Foo foo = FOO_PROPERTY.getValue(httpServletRequest::getAttribute); // or Foo foo = FOO_PROPERTY.getValue(someClientRequestContext::getProperty); // or Foo foo = FOO_PROPERTY.getValue(ThreadLocalStorage::getPropertyValue); // there are similar operations for writing property values: Foo foo = ...; FOO_PROPERTY.setValue(someContextMap::put, foo); FOO_PROPERTY.setValue(httpServletRequest::setAttribute, foo); FOO_PROPERTY.setValue(someWebTarget::property, foo); FOO_PROPERTY.setValue(someClientRequestContext::setProperty, foo); FOO_PROPERTY.setValue(ThreadLocalStorage::setPropertyValue, foo); // and remove operations FOO_PROPERTY.removeProperty(someContextMap::remove); FOO_PROPERTY.removeProperty(httpServletRequest::removeAttribute); FOO_PROPERTY.removeProperty(someClientRequestContext::removeProperty); FOO_PROPERTY.removeProperty(ThreadLocalStorage::removeProperty);
This very small framework is especially useful when you have to pass around properties e.g. from / to filters and interceptors which use different APIs to manage context properties.

Note that for easier version management the version of the SoftSmithy Development Utility Library is aligned with the version of the SoftSmithy Utility Library. As the SoftSmithy Development Utility Library has a dependency on the SoftSmithy Utility Library it's recommended to use the same version of both libraries!
<dependencyManagement> <dependencies> [...] <dependency> <groupId>org.softsmithy.lib</groupId> <artifactId>softsmithy-lib</artifactId> <version>2.0</version> <scope>import</scope> <type>pom</type> </dependency> [...] </dependencies> </dependencyManagement>

You can find the latest Javadoc here: Javadoc

I deployed the artifacts (including the source and javadoc artifacts) to Maven Central.

News from the Software Smithy: Version 1.0 released

SoftSmithy news: after the releases v0.8 and v0.9 last year (I didn't blog about those), I've recently released the version v1.0 of the SoftSmithy Utility Library and the SoftSmithy Development Utility Library.

With this release I changed the version policy. I'm using now the major version part as well to make it easier to distinguish between major requirement changes such as the Java version and the JUnit version (required by the JUnit helper classes):

• v1.x: Java SE 8 and JUnit 4 based
• v2.x (future): Java SE 8 and JUnit 5 based (likely)
• v3.x (future): Java SE 11 and JUnit 5 based (likely)

The released JARs contain the Automatic-Module-Name Manifest entry to make the transition to Java SE 11 smoother.

Note that for easier version management the version of the SoftSmithy Development Utility Library is aligned with the version of the SoftSmithy Utility Library. As the SoftSmithy Development Utility Library has a dependency on the SoftSmithy Utility Library it's recommended to use the same version of both libraries!

You can find the lates Javadoc here: Javadoc

I deployed the artifacts (including the source and javadoc artifacts) to Maven Central.

Drombler FX: Version 0.12 and 0.13 released

Since introducing a modular StatusBar and ProgressMonitor earlier this year, I've released v0.12 and v.013 of Drombler FX - the modular application framework for JavaFX.

In this releases some of the Drombler FX/ ACP start-up code has been moved to Drombler Commons.
This allows also non-Drombler FX/ ACP applications, such as the Drombler JStore Client Agent, to reuse start-up code such as:

• distinction between user directory and installation directory
• simple command line arguments / switches support 
• extendable BootServiceStarter framework 
• "single instance" support, which makes sure the application runs only once per user directory and passes the command line arguments to the running single instance

Because the code has been moved, please note that some of the packages and Maven dependencies changed as well.

Please also note that org.drombler.commons.fx.scene.GraphicFactory moved to org.drombler.commons.client.graphic.GraphicFactory with these releases.

 

Small Enhancements

There are small enhancements to work with directories, data handlers, collection bindings and TreeViews. 

Please check the documentation to learn more about them.

Additional Information

Projects like this one need to be build by a community working together to be really successful. There are several ways how you can contribute to this project. Contributions are highly welcome! See the "How to Contribute"-page for more information.

You can find the complete list of fixed issues here: https://github.com/Drombler/drombler-fx/issues?q=milestone%3A0.13


There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.


The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
  

Name	Modules (incl. Maven Coordinates)	Javadoc	Description
Drombler FX	Modules	Javadoc	Drombler FX, the modular application framework for JavaFX based on: OSGi Maven (POM-first) a declarative programming model Drombler ACP  Drombler Commons.
Drombler ACP	Modules	Javadoc	Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on: OSGi Maven (POM-first) a declarative programming model Drombler Commons.
Drombler Commons	Modules	Javadoc	Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment.

If you find issues or have enhancement requests, you can file a ticket here: https://github.com/Drombler/drombler-fx/issues.

 

Drombler JStore News: JRE REST service and JAP packaging

The work on the Drombler JStore, the next generation of Java application deployments, goes on.

The way an application is identitfied has been changed to reuse the Maven GA(V) coordinates: groupId + artifactId
The packaging format is fixed (currently it's called "jap") and together with a version an application package can be uniquely identified.

There are now 4 REST services:

• search for application updates (currently uses mock data)
• new: download an application (currently mocked)
• new: search for JRE updates (all recent versions of Oracle Java SE 8 and 10 supported!)
• new: download a JRE (Swagger does not work yet here, but the service can successfully be called by the Drombler JStore Client Agent)

The search services already get called by the Drombler JStore Client (JavaFX based rich client).

The Drombler JStore backend service is now open sourced, too. This allows to discuss how we want to implement things and opens up for contributions.

The following JSON shows how we could manage JRE versions:

{ "jreImplementationInfos": [ { "javaSpecificationVersion": "10", "releases": [ { "jreVersion": "10.0.2+13", "releaseDate": "2018-07-17", "platforms": [ { "osName": "linux", "osArch": "x64", "url": "http://download.oracle.com/otn-pub/java/jdk/10.0.2+13/19aef61b38124481863b1413dce1855f/jre-10.0.2_linux-x64_bin.tar.gz", "checksums": [ { "algorithm": "sha256", "hashValue": "7d2909a597574f1821903790bb0f31aaa57ab7348e3ae53639c850371450845d" } ] }, ... { "osName": "osx", "osArch": "x64", "url": "http://download.oracle.com/otn-pub/java/jdk/10.0.2+13/19aef61b38124481863b1413dce1855f/jre-10.0.2_osx-x64_bin.tar.gz", "checksums": [ { "algorithm": "sha256", "hashValue": "a0ccfa98028ecbfd8081fc865bb8d0b32b6fd7f815e5b9695853831af3ba0963" } ] }, { "osName": "windows", "osArch": "x64", "url": "http://download.oracle.com/otn-pub/java/jdk/10.0.2+13/19aef61b38124481863b1413dce1855f/jre-10.0.2_windows-x64_bin.tar.gz", "checksums": [ { "algorithm": "sha256", "hashValue": "cc5362d17c8baaa84c6bc63bba79fe8c2ec3d2ff2a2ec239482ae0b7cf03887a" } ] }, ... ] }, { "jreVersion": "10.0.1+10", "releaseDate": "2018-04-17", "platforms": [ ... ] } ], "endOfLifeDate": "2018-09-30" }, { "javaSpecificationVersion": "8", "releases": [ { "jreVersion": "8u181-b13", "releaseDate": "2018-07-17", "platforms": [ ... ] }, { "jreVersion": "8u171-b11", "releaseDate": "2018-04-17", "platforms": [ ... ] } ], "endOfLifeDate": "2020-12-31" } ] }

You can find the complete file here. There is also a JSON Schema.

Also work has gone on with the application desriptor specification. 
Here is a sample:
{ "applicationId" : { "groupId" : "org.drombler.jstore.client.agent", "artifactId" : "drombler-jstore-client-agent-application" }, "version" : "0.1", "managedNativeComponents" : { "jreInfo" : { "jreVendorId" : "Oracle Corporation", "javaSpecificationVersion" : "10", "customJREId" : "", "modules" : [ ] } } }

You can find the accordant JSON Schema here.

The JAP Maven Plugin can generate an application descriptor for you. You can find the Maven Plugin documentation here.

The project is moving forward and contributions are highly welcome! The current code base is not very complex. You should be able to get started quickly. Please don't hesitate to ask me, if you have any questions.

We can use your inputs especially in the following areas:

• What should the platform-independent application packaging format and meta data look like to support your applications? What information is needed by the agent? What information is only needed by the discovery feature of the rich client?
• Help us to make sure the agents have the necessary native OS integration to support your applications.
• Help us to create a great user experience with the rich client (some UX and JavaFX skills required)
• Help translate the texts of the rich client to different languages (i18n/ l10n)
• Help us to get the basic features of the agent right
• File enhancement requests for the various components
• Join the discussions in the issues or on Gitter.
• Help with the documentation (GitHub Pages, README files)

Since the proposed solution requires a backend, this will also require some resources to run the service. Any donations are welcome!

The next generation of Java application deployments

A lot is going on in the Java world. So let's first have a look at where we currently are.

Oracle discontinues Java Web Start with Java 11

After discontinuing the Applet technology, which required browser plug-ins, Oracle now announced that they will also discontinue the Java Web Start technoloy.

Java Web Start, however, was a great way to easily deploy Java applications. It made sure Java application deployments don't fall too far behind the instant deployment feature of web applications - a point which already let many companies to choose web applications over Java based applications.

With Java Web Start gone, it will become harder again to compete with web applications, if we don't find a good alternative (please read on).

Oracle changed to a biannual major Java release cadence

Every 6 month there will be now a new "major" Java version, though the term "major" likely won't be used anymore and differences will be smaller than with the 2-3 year cadence (see Java 8 -> Java 9 vs Java 9 -> Java 10).

With every "major" release the support of the previous release seems to be discontinued.

Every 3 years there will be a LTS (Long Term Support) version, starting with Java 11 targeted for September 2018 (there is a small video and a FAQ about this from Oracle).

As far as I understand (please correct me if I'm wrong) you will need to buy this LTS. If you don't, then it's recommended to upgrade to the next major version or find another distributor which provides updates (more on this see below).

Interestingly and to some surprise, the long awaited Java SE 9 release with the new module system didn't become a LTS version and already has been superseded by Java SE 10.

Oracle also mentions that developers often package the JRE with their applications nowadays. End users should not need to install a JRE anymore.

Oracle and OpenJDK binaries

While Sun started to open source the JDK with the OpenJDK project back in 2006 and Oracle continued this process, there are still some differences between the OpenJDK builds and the Oracle Java builds.

Now Oracle plans to ship OpenJDK binaries for non-LTS releases and with this shift they also plan to finally close those technical differences, which currently still exist.

Once these differences are closed, this will make projects such as AdoptOpenJDK much more appealing, as it seems they will provide free updates for LTS versions in the future.

Modular JRE and JLink

Together with the JPMS (Java Platform Module System), which modularizes the JRE and can be used to modularize applications, Java 9 introduced a new tool called JLink.

JLink allows you to create custom runtime images which only consists of your application modules and those JRE modules which your application requires.

The result is likely a smaller runtime image which uses less resources than using a default JRE.

This should also make Java more appealing to IoT devices.

JavaFX

Since JavaFX 2.2 and Java SE 7 update 6, JavaFX has been included in Oracle's JDK. With JavaFX 8 and Java SE 8 the version has been aligned and JavaFX has become available on the default classpath.

Now Oracle announced (see the link at the top) that with Java SE 11 JavaFX will be removed again from the JDK.

With a modularized JRE it might be more natural to let feature modules have their own cycles.

But since JavaFX also includes native parts, it seems to me WORA (Write Once, Run Anywhere) will become a bit trickier - at least the packaging part of JavaFX applications.

Please read on for a possible solution.

The Java Packager Tool

JavaFX also introduced a new tool to create platform-specific native packages with an embedded JRE. With JavaFX 8 the tool has been added to the JDK as the javapackager tool.

Since Java SE 9 the javapackager tool integrates with the jlink tool.

In Java SE 11 the javapackager tool will be removed again from the JDK along with JavaFX.

There is a JEP request (JDK Enhancement Proposal) for a new jpackager tool, however.

While I think we do need a tool such as javapackager/ jpackager, javapackager and the proposed jpackager also have some major drawbacks:

• no cross-compilation support: You have to create the native packages on the target platforms, e.g. msi-packages on Windows, deb-packages on Linux. Creating a one-click release pipeline is non-trivial.
• platform specific configurations: Each native package has slightly different requirements.
• no automatic security updates: The users have to rely on the application vendors to ship a new application version which contains a JRE with the latest security fixes (though not all security bugs might affect all applications in the same way).
• expensive managed deployments: In heavily managed enterprises, where the average users don't have local admin rights and can't install applications themselves, the processes of application deployments tend to get very expensive (up to several thousand CHF per deployment). This is another reason why enterprises nowadays tend to either Java Web Start or to web applications.
• slow managed deployments: In these heavily managed enterprises, deployments also tend to be slow and can take up to several weeks until the application is deployed to the user machine. This also makes it hard to coordinate frontend deployments with backend deployments and is definitely not DevOps-friendly. This is yet another reason why enterprises nowadays tend to either Java Web Start or to web applications.

Drombler JStore

Given the above mentioned issues with tools such as  javapackager/ jpackager, which create application packages with an embedded JRE, I don't think this is the solution for the majority of Java applications.

On the other hand, I too think that we should not require anymore from end-users to pre-install a JRE, which likely doesn't fit for all applications anyway.

It's however unlikely that Oracle will provide another solution than the jpackager.

If we need something different then it will have to be community driven.

So I'm proposing here a new deployment model with the working title (likely to change): Drombler JStore

At the core of this deployment model is a new application store with first class support for Java applications.

In general, most applications should be able to define a platform-independent package which also describes the dependencies to some managed native components such as the JRE.

The tooling will then make sure that the required native components are available on the end-user machine. The tooling will also configure the environment for the process which starts the application.

The currently proposed solution consists of 4 major software parts.
I've already written a PoC (Proof of Concept) for each of those, which I think can serve as a starting point. Please note that everything is still subject to change.

• Drombler JStore Client Agent:
• Current goals:
• headless background service
• targets: end-user devices (desktops, NAS, IoT devices,...)
• download and update applications from Drombler JStore
• download and update applications using a JNLP-like file
• download and update native components:
• JREs (supporting multiple parallel major version installations)
• custom runtimes created by JLink (supporting multiple parallel major version installations)
• JavaFX native components?
• Other native components, e.g. SWT?
• support Security Manager
• start applications in a configured environment
• OS integration: 
• desktop shortcuts
• URL protocol registration
• run as native OS service/ deamon
• PoC:
• Access a first Drombler JStore REST service
• Download a JRE from Oracle
• GitHub: https://github.com/Drombler/drombler-jstore-client-agent
  
• Drombler JStore:
• Current goals:
• a free service (backend) run by Drombler
• Provide access to applications / application updates
• Provide access to native components and updates (JREs etc.)
• Search applications
• Rate applications
• Comment on applications
• Register vendors
• Provide vendor contact options
• PoC:
• a first deployed REST service is available (likely to change)
• Swagger: http://drombler-jstore-staging.us-east-1.elasticbeanstalk.com/swagger-ui.html
  
• Drombler JStore Client: 
• Current goals:
• JavaFX-based rich client
• Remote management of multiple Drombler JStore Client Agents
• Discover applications on Drombler JStore
• Rate applications on Drombler JStore
• Comment on applications on Drombler JStore
• Register vendors
• PoC:
• Drombler FX-based rich client
• Initial multiple Drombler JStore Client Agent management support
• Plugable feature support
• Connect to the Drombler JStore REST service
• GitHub: https://github.com/Drombler/drombler-jstore-client
  
• JAP Maven Plugin
• Current goals:
• Define a platform-independent application packaging format and meta data
• Provide Maven tooling
• PoC
• Creates a ZIP-based package, which contains the application in a nested ZIP-file. 
• GitHub: https://github.com/Drombler/jap-maven-plugin 
• in the future there could be similar solutions for other build tools such as Gradle

Call to the Community

As mentioned above, if we need a different deployment model then it will have to be community driven.

What do think about this proposed solution?
Do you have a need for an alternative deployment model?
Do you think we're running in the right direction with this proposed solution or did we miss something?

Contributions and Donations 

Even for a MVP (Minimal Viable Product) there is quite some work to do.
Contributions are highly welcome! The current code base is not very complex. You should be able to get started quickly. Please don't hesitate to ask me, if you have any questions.

We can use your inputs especially in the following areas:

• What should the platform-independent application packaging format and meta data look like to support your applications? What information is needed by the agent? What information is only needed by the discovery feature of the rich client?
• Help us to make sure the agents have the necessary native OS integration to support your applications.
• Help us to create a great user experience with the rich client (some UX and JavaFX skills required)
• Help translate the texts of the rich client to different languages (i18n/ l10n)
• Help us to get the basic features of the agent right
• File enhancement requests for the various components
• Join the discussions in the issues or on Gitter.
• Help with the documentation (GitHub Pages, README files)

Since the proposed solution requires a backend, this will also require some resources to run the service. Any donations are welcome!

Further Readings

Here are some further blog posts about similar topics:

• https://dzone.com/articles/what-the-future-java-releases-will-mean-for-legacy
• https://medium.com/codefx-weekly/no-free-java-lts-version-b850192745fb

Conclusion

A lot is going on in the Java world. But these changes also provide opportunities for new solutions.

Join and help to shape the next generation of Java application deployments!