Tag: java

Building a layered modular Java application? Watch out for these!

Posted on by aalmiray

Recently I’ve been experimenting with building layered modular Java applications with Layrry, a launcher and Java API for executing modularized Java applications. It so happens that version 1.0.0.Alpha1 was just released a couple of weeks ago, making it easier for anyone to give it a try. The base concept of Layrry is to organize your code in such a way that modules are grouped in a series of layers, enabling isolation between said layers as there’s a single classloader per layer, thus allowing conflicting modules (such as binary incompatibilities between classes) to be used within the same application. Module layers Read More

Layrry 1.0.0.Alpha1 has been released!

Posted on by aalmiray

A brand new day brings a brand new release: I’m ecstatic to announce that Layrry 1.0.0.Alpha1 has been released! You can find all artifacts at Maven Central, Bintray, download them from Layrry’s releases page, or build it yourself by cloning https://github.com/moditect/layrry.git and following the build instructions found in the README, basically mvn install (yup, install is needed in this case, you can skip the clean). What’s more, you can also install Layrry directly from SDKMAN! as it’s now available as a candidate. 🤩😱😍🥳 #Layrry at @sdkman_ pic.twitter.com/Kgu1BrsCaO — Andres Almiray (@aalmiray) January 30, 2021 What’s all the fuzz about Layrry Read More

Maven: verify or clean install?

Posted on by aalmiray

This is it. After months of tweeting memes about mvn clean install I decided to get some numbers to see how performance would be affected when switching from one command to the other. But first a bit of history. Like many developers when faced with building a Maven project the first reaction is to invoke mvn clean install, after all you find that instruction in almost every README or BUILD file, so why question it? It does not matter if the project is single or contains multiple modules, the instruction is the same. As a matter of fact when the Read More

Running Java code from the source

Posted on by aalmiray

Java 11 comes with a bunch changes and features (17 as listed here) one of which is JEP 330 which grants the ability of running a program from source without a separate compilation session; in other words you can now compile and run code in one go. JEP 330 describes the rules that must be followed to make use of this feature such as: A single source file ought to be provided as argument, additional files are ignored. The code must not have external dependencies other than java.base module. The code is compiled under the unnamed module. Program arguments may Read More

Ikonli 11.0.0 Released

Posted on by aalmiray

Celebrating the recent release of JavaFX 11 and the upcoming release of Java 11 (any moment now!) I’d like to announce that Ikonli 11.0.0 is out! Judging by its number you can tell that this release synchronizes with both JavaFX 11 and Java 11. This release provides 30 icon packs (the same number as 2.4.0) but it requires Java 11 as a minimum. All artifacts have been fully modularized and take advantage of JPMS. You can configure and run your application on the module path or in the classpath, either way Ikonli will resolve your favorite icons. If running on Read More

DesktopPaneFX 0.9.0 released!

Posted on by aalmiray

Version 0.9.0 of DesktopPaneFX has just been released! You can download it directly from Bintray’s JCenter and/or Maven Central. This version delivers the following changes: The title bar has been moved out from InternalWindow into its own component: TitleBar. This is a breaking change as some properties and methods have been migrated to the new class. InternalWindow can only be dragged from its title bar. Previous versions allowed dragging from anywhere within the window. InternalWindow now exposes a resizable property. There’s also a new incubating feature that made the cut: the ability to detach and attach windows to a DesktopPane. Read More

Creating aggregate JavaFX bindings

Posted on by aalmiray

The standard JavaFX API provides a class named Bindings that can be used to create all kinds of bindings your application may need. Methods in this class can be used to translate any Observable, ObservableValue, Binding, Expression, and/or Property into another Binding, regardless of their original type. Here’s for example how you could translate a StringProperty into an IntegerBinding, by exposing the length of the contained String: StringBinding sourceBinding = … // initialized elsewhere IntegerBinding lengthBinding = Bindings.createIntegerBinding( () -> sourceBinding.get().length(), sourceBinding); While quick and to the point we’re forced to read the value directly from the inputs (in this Read More

Announcing DesktopPaneFX

Posted on by aalmiray

Recently at work we faced the need of implementing a user interface that delivered similar features as the ones exposed by Java Swing’s JDesktopPane but for JavaFX. Unfortunately JavaFX does not provide such component out of the box, nor do the most common JavaFX controls projects out there. There are however a few attempts to put something together but most never left the prototype stage or have been abandoned. That’s how I found JavaFXMDI, which seemed to have the right approach but was left unattended for close to 3 years. Fortunately the code was published as Open Source, thus after Read More

May Java be with You!

Posted on by aalmiray

May was quite a hectic but fun month for me. The month began with a new state of mind as I found myself without a job albeit not for long as I’d join my next employer at the beginning of June, and though that was the plan all along I couldn’t shake the feeling of having to cut short a particular experience just to get back to work e-mails. Despite finding myself unemployed for a month I didn’t get much time to slack off as the next 5 weeks proved to be quite the ride round the globe (quite literally!) Read More

Customize JAR manifest entries with Maven/Gradle

Posted on by aalmiray

How many times have you found yourself in a situation where you can’t tell if the artifacts used by the application are the correct ones or not? How many times have you looked at a bug report stating that the problem is caused by version X of a particular artifact but you are certain the bug was fixed in said release? On closer inspection (after unpacking, debugging, even decompiling!) you find that the artifact in production is not the right one even though the version appears to be the correct one. One option we have to mitigate this problem is Read More

ˆ Back To Top