These scripts and config files automate installation of latest stable vanilla Minecraft server on Linux using systemd, also setting up mcrcon for easy administration:
https://github.com/odoepner/minecraft-server-installation
Any feedback is greatly appreciated.
Many applications need Undo/Redo functionality. Commonly used implementation patterns are:
When using the Command Pattern one would encapsulate both the change logic and its reversal in command objects. Undo/Redo is implemented by managing stacks of those objects. This approach has its limitations, for example for changes that are unidirectional in nature, like anything involving randomness, encryption, etc.
State snapshots save the full state of the edited data as object graphs or some representation thereof. This is also called the Memento Pattern. It often uses serialization and typically compression of the object graph to reduce memory use and ensure immutable snapshots that can also be stored out-of-process, if desired.
State diffs are based on the idea of State snapshots, but only store the difference between states. This can vastly reduce memory consumption of your Undo/Redo history. It is based on diffing algorithms that compute the delta between two states (or their memento) and allow Undo/Redo by applying the deltas as patches against a given state. A disadvantage is that jumping to a state involves a whole chain of patch applications. But it is a good approach when the user mainly navigates the Undo/Redo history sequentially.
A highly reusable implementation of Undo/Redo using State Diffs is available at my github account: https://github.com/odoepner/diffing-history
It uses the following Open Source libraries:
It provides the following features:
It is Open Source under the Unlicense.
The main API is the History interface.
Create an instance of DiffingHistory to get started.
The DiffingHistoryTest calls all History methods and illustrates the API.
Now that Oracle Java 8 is no longer free-of-charge for commercial use, and Oracle is dropping Webstart, you might be looking for an alternative way to let your users still execute your Webstart based Java applications.
There are two community based projects that provide OpenJDK builds for various platforms for free and who have committed to providing security update builds for an extended time:
The Java 8 MSI installer from ojdkbuild has options for installing OpenJFX, Webstart (the Open Source implementation from IcedTea-web) and an Update notifier.
The AdoptOpenJDK team is working on a similar package, also offering IcedTea-web.
Overall, it seems that Oracle’s move to charge commercial users for Java might be a good boost for OpenJDK community builds.
Security updates for Java 8 until 2023 and for Java 11 until 2024, are made possible by Redhat taking over the respective OpenJDK Updates projects.
Let’s say we have an Apache Camel route with an entry point like this:
from("direct:start")
// other route steps
How to trigger “direct:start” from the command line?
Use JMX
The JMX instrumentation agent is enabled in Camel by default.
In Camel 2.9+ no special jars are required for JMX.
For details, see the Camel JMX documentation.
On the same computer and as the same user, execute jmxterm like this:
java -jar jmxterm-*-uber.jar -l ${pid} -i jmxterm-script.txt
With a file jmxterm-script.txt like this:
bean org.apache.camel:context=camel-1,name="camel-1",type=context run sendStringBody "direct:start" ""
This calls sendStringBody(..) on the ManagedCamelContext and triggers the route for you.
Note to self: If you create a Java application and think you need DI but not AOP, then do not automatically reach for containers like Spring, CDI, Guice. Just do all construction and wiring in the standard main method.
Example: https://github.com/odoepner/bagh-chal/blob/master/src/main/java/org/oldo/baghchal/Main.java
Anil Gaul’s keynote showed a JEE8 plan with new scope and release targets.
Oracle says JEE must adjust to trends like cloud and microservices.
The ambitious roadmap aims for JEE8 release in 2017 and JEE9 in 2018:
The scope changes include two new JSRs: “Configuration” and “Health Check”:
Surprisingly, Oracle wants to remove MVC and JMS 2.1 from JEE8 scope.
Allegedly they are “no longer very relevant in the cloud”.
Unfortunately, the roadmap also no longer mentions JCache.
The proposed JEE8 architecture stack is very focused on Java for light-weight web services:
More details are in the “Java EE 8 Update” by Linda DeMichiel:
I found the basic idea here, the exact steps are:
for /R %f in (.\*.pack) do @"%cd%\bin\unpack200" -r -v -l "" "%f" "%~pf%~nf.jar"
Kudos to Nick Russler for figuring out this tricky unpack200 command line!
First we determine the process id(s) of the running Tomcat instance(s).
We can grep the running process list for ‘catalina.home’:
pgrep -f 'catalina.home'
This might yield more than one pid.
Or we can search by port (8080 is the default, adjust if necessary). The following commands will likely require root privileges:
lsof -t -i :8080
Alternatively, for example if lsof is not installed:
fuser 8080/tcp
Or yet another way, using netstat (or its “ss” replacement):
netstat -nlp | grep 8080
ss -nlp | grep 8080
For the process id(s) determined above, we look at process details:
ps -o pid,uid,cmd -p [pidlist] | cat
For each specified pid, this shows the uid (system user) and the full command line of the process.
Typically the command line will contain something like “-Dcatalina.home=[path]” and that path is the catalina.home system property of the Java process.
Alternatively – with Java 7 and later – we can use the JDK command “jcmd” to query the JVM process for its system properties:
sudo -u [uid] jcmd [pid] VM.system_properties \ | grep '^catalina.home' \ | cut -f2 -d'='
Now we can finally determine which Tomcat version is installed under the catalina.home path:
[catalina.home]/bin/catalina.sh version \ | grep '^Server number:'
Note: Please replace [catalina.home] with the path you determined above.
The final output should be something like this:
Server number: 7.0.56.0
Suggestions for other/better Free/Open Source plugins for current Intellij CE are welcome:
Let’s say you work on a Java application and want to frequently make it available for download so that user’s can easily try the latest version.
Let’s say you work primarily on your laptop or personal computer using a Java IDE and commit code changes, but you don’t want to spend time manually building jars, packaging war or zip files, testing your application or uploading files to a website, etc.
Instead you want to have a fully automated process that compiles your source code, runs automated tests and other quality control mechanisms, builds your application and uploads the result to a public website.
But you don’t want to install any infrastructure for this and not run anything besides Java and your IDE on your own machine(s).
Basically you want to use developer-friendly reliable cloud services but you don’t want to pay a single cent.
All of this is possible, as long your code is Open Source:
For details, you can take a look at one of my github projects.
Relevant config files:
Oleander Donovan's IT blog 