[b][url=/bee-config]Bee Config[/url][/b], the simple Scala API for loading configuration files, has needed very few changes over the last few months and is now in preparation for full release. It is feature-complete and mostly ready for production use. It now has a Maven/Ivy repository for automatic dependency. If no significant changes are needed during December, the first release candidate will be announced in a few weeks.
Version 1.4.0 of Bee Config is now available. This follows two enhancements. Firstly, the reloader tool has been improved. Secondly, it is now possible to wrap a config and register it as a JMX bean, allowing a configuration to be accessed and modified by standard JVM tools whilst the program is running.
Version 1.4.2 of Bee Config is now available. This is a bugfix release. ConfigSource now has a canBeOpened method. SourceChangeDetector has been simplified by using the canBeOpened logic. ConfigSource has been modified to ensure that the counter is always updated. History of commits
Version 1.5.0 of Bee Config is now available. This brings full Java support, whilst carrying forward the excellent Scala api. In previous versions, file i/o, parsing and config manipulation were all written in Scala, which was less easy to use from Java programs. Now, a new ConfigJ class in Java emulates the Config class in Scala. The Java parser is shared by both. The file i/o and parsing have been back-ported to Java, although this will not be evident in existing Scala programs (unless they happen to use the underlying utility classes explicitly).
Version 1.5.3 of Bee Config is now available. This brings JavaBean integration, a new feature for those who would like easy configuration files combined with pojos with typed properties. The new feature allows you to load your Config from a file (or wherever) as normal, then use it to populate JavaBeans, which may themselves contain further JavaBeans. You can create your own JavaBean and pass it in. Or you can specify the class of the bean and it will be created reflectively for you.
Version 1.5.4 of Bee Config is now available. This brings support for Scala 2.11 as well as 2.10 and 2.9.x. Previous announcement: v1.5.3 History of commits
Version 1.5.5 of Bee Config is now available. This includes a small bugfix in the DimensionedValue class, which now treats kilograms (kg) as a special case. Previous announcement: v1.5.4 History of commits
The CPA2014 conference held in Oxford over the last few days brought together an interesting group of around three dozen experts in the field of communicating process architectures. Discussions were on concurrency and parallelism topics, both theoretical and practical, in areas related to communicating process architectures (CPA). Also known as process-oriented programming, CPA is about both concurrency (the natural expression of things that are happening alongside each other) and parallelism (the physical execution of many parts of a program at the same time) by means of process algebra formalisms and CSP in particular.
Can decision-makers realistically steer their development projects from Java to Scala yet, or is it too early? Clearly, such a transition is not without risk. Have the benefits now stacked up to outweigh the risks? An excellent blog post by Jim McBeath discusses the pros and cons in an objective way. This is well worth reading. Paulo Vilella of Accenture added his views: “For small to medium projects, I believe Scala is right now a great alternative to Java for higher productivity and agility, without compromising on performance and compatibility.
A significant part of the lines of code in any enterprise Java application are devoted to plain old java objects (pojos) that carry data. Although they are simple, they represent a non-trivial effort in development and testing. And they make an application resistant to change because often a small change requires alteration of code in several places. Pojos written in Scala are so simple that the value of mixing Scala into Java development becomes worth the extra startup effort.
A Java logging framework should be effective but low fuss. There are many to choose from - some would say too many perhaps. What is needed is something that is simple, productive, reliable and with good performance. SLF4J is a façade for logging in Java that achieves best-of-breed capability and plays nicely with pre-existing frameworks. Log4J - the Forerunner Probably the most successful earlier logging framework was Log4J, a well-respected Apache project.
Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application. Scala - The New Kid on the Block Actually not so very new, Scala was initially developed during 2001 - 2003.
A particularly important objective for developers producing of concurrent systems is to produce designs that always give consistent results and cannot deadlock (see The Four Horsemen on why this can be difficult). Since Java 1.5, the Java API has included the java.util.concurrent package, which contains a range of classes to support thread synchronisation, communication and safe sharing of data. This Java5 API enhancement introduced blocking queues for passing messages between threads, and with this it has been possible to write concurrent Java applications that benefit from decades of theoretical progress in how to design deadlock-free systems.
XML documents typically refer to external entities, for example the public and/or system ID for the Document Type Definition. These external relationships are expressed using URIs, typically as URLs. However, if they're absolute URLs, they only work when your network can reach them. Relying on remote resources makes XML processing susceptible to both planned and unplanned network downtime. Conversely, if they're relative URLs, they're only useful in the context where the were initially created.
Test-driven development (described on Wikipedia) is now widely accepted as the preferred way to develop software, especially Java software. I'm an enthusiastic supporter of this predilection - but there is a problem people seem often to overlook. I call it The Four Horsemen (also on Wikipedia) because there are four potentially major dynamic problems unreachable by testing alone. The problems are: Race Conditions - instability due to concurrent threads changing shared data without sufficient protective locking Deadlock - freezing-up of concurrent threads that have a mutual dependency that cannot ever be satisfied Livelock - similar to deadlock, livelock is a condition in which concurrent threads waste time trying to acquire resources that cannot ever be satisfied due to the mutual dependency between the threads.
‘final’ - underused or overrated? The famous Gang of Four made people sit up and take notice that we developers normally do similar things to each other, and the similarities can be effectively expressed as design patterns. Because of the object oriented nature of Java, it is a language that is well suited to patterns; nowadays design patterns are the industry norm. However, there is an important pattern that seems to have been overlooked - probably because it’s so obvious.
I've always been one of those perhaps slightly annoying people who don't easily accept propositions that seem overly intricate. It's not that I'm a stroppy person - I'm pretty relaxed really - I just don't like wastefulness, and that can mean I'm unhappy when I see other people wasting their time doing things the hard way. I suppose I was trained this way by the years I spent working with the Occam programming language, a language that espouses explicitly the avoidance of complexity by making behavioural semantics really clear to the developer.
I wrote about the Spring Framework Mission Statement earlier. This article follows it by examining the second Spring mission statement bullet, which concerns the use of interfaces in Java: It’s best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero. Everyone knows this is a Good Thing - but why is it good? The answer lies in achieving decoupling. Object oriented programming in Java draws on the precedent set by Smalltalk in which objects communicate by passing messages.
© Copyright 2012 Rick Beton Published under The MIT License. The MIT License Copyright (c) 2012 Rick Beton <rick@bigbeeconsultants.co.uk> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Thu, 20 Jun 2013 v1.4.0 Reloader enhanced to offer more robust multithreading support new SourceChangeDetector class hived off Reloader (it could be used for any file-based cache) Thu, 20 Jun 2013 v1.3.1 - New MutableConfig refactors out the parts of the JMX bean needed for mutability from the parts needed for JMX integration. Thu, 20 Jun 2013 v1.3.0 - added support for JMX (experimental): A Config instance can be inserted into a JMX MBean with operations that allow values to be queried and altered.
Config is loaded once only, when it is constructed. You can use Reloader to load changes on the fly if you want to. Reloader is constructed using a File or other source, and a max age in seconds import uk.co.bigbeeconsultants.bconfig.Reloader val reloader = Reloader(new File("src/test/resources/sample2.txt"), 10) Reloader wraps Config loading so that changes to the source can be reloaded dynamically. If the config file is edited whilst the application is running, the new values are loaded in.
A Config subsection is itself a Config instance - it’s easy to group your keys therefore. Here’s a sample file we’ll be discussing: xx.a.z1 = alpha-xx xx.a.z2 = beta-xx xx.b.z3 = gamma-xx xx.b.z4 = delta-xx [yy] a.z1 = alpha-yy a.z2 = beta-yy [zz] a.z1 = alpha-zz a.z2 = beta-zz There are two ways to deal with sections and hierarchies of settings. Prefixes The crudest is simply by choosing a common prefix on all the keys in the group.
Config extends ListMap, making it very easy to use. It assumed that you are familiar with Scala’s Map (and ListMap) collection classes. For clarity, the following examples have the explicit type declared on each val, which is not usually necessary in Scala. Here’s a sample file we’ll be discussing: a = something b = else easy = true tau = 6.2832 somewhen = 1979-05-27T07:32:00Z coronation = 1953-06-02 triangle = 3, 4, 5 actors = "\"Harry\", Daniel Radcliffe", "\"Ron\", Rupert Grint", "\"Hermione\", Emma Watson" timeout = 60s maxHeap = 2 GiB maxTemp = 90°C Simple Cases ∘ Load a string value directly.
Scala API Simply construct Config instances using the factory method. import uk.co.bigbeeconsultants.bconfig.Config val config = Config(new File("src/test/resources/sample1.txt")) You can create a new Config instance from a File or anything that provides an InputStream. Or use the Config.fromClasspath method to read a resource from the classpath. When constructing a Config, you can include another Config as a fallback source of default values; this too can have a fallback so a chain of any length of them is possible.
1. The Config File Writing your config file is easy. It’s like a java.util.Properties file except it must be Unicode (ISO-10646) encoding, not ISO-8859 or some such. Nowadays there are plenty of tools to transcode text files, notably uconv on Linux/Unix computers, various IDEs, native2ascii in the JDK tool suite may be useful in some cases. The config file may optionally start with a Unicode byte-order-mark (BOM) and this is required for automatic switching between UTF-8, UTF-16 and UTF-32.
Bintray Scala 2.11 Scala 2.10 Option 1: Maven / Ivy dependency Please use the Set Me Up link you’ll find on one of the ‘Download’ pages, above. Option 2: manual download Browse one of the ‘Download’ pages, above. Choose a version and navigate to the Files tab to find the jars. Download the jars and put them on your classpath. You need bee-config_1.X.X.jar and you may find the javadoc and source jars useful during development, too.
Bee Config provides a very simple Java and Scala API for loading configuration files. Config files become Maps Simplicity is the key! Still often used in Scala applications, java.util.Properties is rarely satisfactory. Bee Config is broadly similar in intent, but pimped to work well in Scala. Why is Bee Config different: well, Properties files are sooo 20th Century. We need something similar, something as simple but something refreshed. We need to move on from ASCII to Unicode.