We Keep Coding

How to instantiate, configure and use a lib/framework in a oo-application?

I decided to split the last part of that question here into a new question here: https://softwareengineering.stackexchange.com/questions/411738/extension-of-classes-where-to-put-behaviour-how-much-direct-access-is-allowe
If i have a lib and i want to use it, i wrote mostly a own class. This class has one method. In that there is the code how to instantiate the lib/framework. Sometimes there are a few more methods, with them i not only instantiate the class but use it. For example if i want to start a http-server i have there a start-method.
class Container
{
TheLib theLib;
public void init() //or a constructor
{
//some init of the theLib
}
public void start() //
{
theLib.doSomething(...)
theLib.doSomethingmore(...);
theLib.start(...);
}
//important!
public TheLib getTheLib()
{
return this.theLib; //after i started configured it and so on, i want of course use all methods,
which the lib have in some other parts in my application
}
}
But it seems not to be the best solution.
Are there any better solutions, that OO is?
Often i also use only one method, a own class for this seems to be here a big overhead?
Exposing the lib breaks encapsulation? Tell-Dont-Ask is also violated?

Everything depend on what you actually need or how you have access to your 'the lib' instance.
public class Container {
private TheLib theLib;
/* #1: Do you already created the instance before? */
public Container(TheLib theLib) {
this.theLib = theLib;
}
/* #2: Do you need to created the instance each time? */
public Container() {
this.theLib = new TheLib();
}
public void start() {
theLib.doSomething(...)
theLib.doSomethingmore(...);
theLib.start(...);
}
public TheLib getTheLib() {
return this.theLib;
}
public static void main(String[] args) {
/* #1 */
TheLib theLib = ...;
Container container = new Container(theLib);
/* #2 */
Container container = new Container();
/* Continue the flow of your program */
container.start();
container.getTheLib().doSomethingEvenMore();
}
}
Or maybe you actually need only one instance of your 'Container' class. In this case, you should look on how to make a singleton: Java Singleton and Synchronization
Anwser: Often i also use only one method, a own class for this seems to be here a big overhead?
Well, in Java, you cannot do formal programming like in C, so everything line of code that you write, or will be using, has to be in a class of some sort.
If your piece of code is small and don't really need an object, static function might do the work.

Verify whether a method parameter is used in the method body

I have an interface which looks like the following
interface Evaluator {
boolean requiresP2();
EvalResult evaluate(Param1 p1, Param2 p2, Param3 p3);
// some more methods
}
This interface is implemented by several classes. The parameter p2 of the evaluate method is used by some and not used by others. The method requiresP2 basically returns a boolean telling whether the evaluate method uses p2 or not.
Now, this questions may appear a little weird out of context but believe me, it makes sense in our use case. Plus, it would require a lot of time to refactor all the code to eliminate the need for the requiresP2 method so I would appreciate if we discuss solutions other than a top-to-bottom refactoring of the codebase.
The problem is that the return value of method requiresP2 is based on how the evaluate method is implemented. Therefore everyone must ensure that they update the requiresP2 method when they change the evaluate method.
I am looking for ways so that this can be enforced by the compiler/unit-tests/linters rather than leaving it to the developer's memory.
EDIT: I am still exploring the applicability of mocking frameworks to this problem.
I thought that I could reflection in unit tests to inspect evaluate's body in the unit test to check if it refers to p2 or not and then making sure it matches with the value returned by requiresP2 method but it seems that it is not possible to inspect method body using reflection.
I am looking for suggestions on how to do this. Any input is appreciated.

There is another option you did not mention: a Static Code Analysis tool.
You can use the SonarQube + SonarLint combination in order to get your desired enforcement:
Use the SonarQube server in order to create a new static code analysis rule, which will be based on the interface you are using and your unique use case.
Then install SonarLint on your IDE/IDEs (Eclipse and IntelliJ are both supported), and connect it to the SonarQube server.
This way the static code analysis scan will detect improper usage of your interface and indicate this with a visual marking in the IDE, on the relevant code lines (which is actually linting your code).

You can use ASM to check whether the parameter is used.
To add it to your project using e.g. Apache Ivy, you would add this to ivy.xml:
<dependency org="org.ow2.asm" name="asm" rev="6.1.1" />
Or do the equivalent for Maven, Gradle, etc. Then you can check on the parameter by:
import java.io.IOException;
import java.io.InputStream;
import java.io.UncheckedIOException;
import java.util.concurrent.atomic.AtomicBoolean;
import org.objectweb.asm.ClassReader;
import org.objectweb.asm.ClassVisitor;
import org.objectweb.asm.MethodVisitor;
import org.objectweb.asm.Opcodes;
// . . .
public static boolean usesP2(Evaluator evaluator) {
AtomicBoolean usesP2 = new AtomicBoolean(false);
String internalName = evaluator.getClass().getName().replace('.', '/');
String classFileResource = "/" + internalName + ".class";
ClassVisitor visitor = new ClassVisitor(Opcodes.ASM6) {
#Override
public MethodVisitor visitMethod(int access, String name,
String desc, String signature, String[] exceptions) {
if ("evaluate".equals(name)) {
return new MethodVisitor(Opcodes.ASM6) {
#Override
public void visitVarInsn(final int insn, final int slot) {
if (slot == 2) usesP2.set(true);
}
};
}
return super.visitMethod(access, name, desc, signature, exceptions);
}
};
try (InputStream is = Evaluator.class.getResourceAsStream(classFileResource)) {
ClassReader reader = new ClassReader(is);
reader.accept(visitor, 0);
} catch (IOException e) {
throw new UncheckedIOException(e);
}
return usesP2.get();
}
public static void assertCorrectlyDocumentsP2(Evaluator evaluator) {
boolean usesP2 = usesP2(evaluator);
if (usesP2 && !evaluator.requiresP2()) {
throw new AssertionError(evaluator.getClass().getName() +
" uses P2 without documenting it");
}
if (!usesP2 && evaluator.requiresP2()) {
throw new AssertionError(evaluator.getClass().getName() +
" says it uses P2 but does not");
}
}
Unit tests:
#Test
public void testFalsePositive() {
assertCorrectlyDocumentsP2(new FalsePositive());
}
#Test
public static void testFalseNegative() {
assertCorrectlyDocumentsP2(new FalseNegative());
}
(This supposes there are two bad Evaluators, FalsePositive and FalseNegative, one of which documents that it uses P2 but doesn't, and the other which doesn't document that it uses P2 even though it does, respectively.)
Note: In usesP2 we check for a variable instruction (an instruction which accesses a local variable) in slot 2 of the stack frame. The slots are numbered from 0, and the first one is this. P2 is in slots 2 only because Evaluator::evaluate is an instance method. If it were a static method, we would have to check if slot 1 were used in order to detect if parameter P2 were used. Caveat lector.

Initializing a JavaBean

I am finding myself making a lot of Classes for use in GUI building (hence they must conform to the JavaBean pattern). This has created some issues for me regarding initialising. I often have some method that is quite time intensive that must be executed once the state has been set.
One approach is to document that the method init() must be executed and hope that people read and respect it, but that is clumsy and means that the GUIBuilder can't just be used as intended, but rather extra code has to be added.
I've checked Bloch's "Effective Java", these forums and of course I asked Dr Google, but I haven't come up with anything. To be fair, it's a bit of a wishy-washy set of search terms.
The following short example (obviously trivialised) demonstrates my current approach. I have an "isInitialised" variable and invalidate the instance whenever a setter is called. Whenever a getter is called on a calculated variable (or any other complicated method), the isInitialised variable is checked and if needed the init() method is called.
public class BeanTest {
private int someValue; // Just some number
private float anotherValue; // Just another number
private double calculatedValue; // Calculated by some expensive process
private boolean isInitialised = false; // Is calculatedValue valid?
/**
* Default constructor made available for JavaBean pattern
*/
public BeanTest() {
someValue = 0;
anotherValue = 0;
}
//******* Getters and setters follow ************/
public int getSomeValue() {
return someValue;
}
public void setSomeValue(int someValue) {
if (someValue == this.someValue) {
return;
}
isInitialised = false; // Calculated value is now invalid
this.someValue = someValue;
}
public float getAnotherValue() {
return anotherValue;
}
public void setAnotherValue(float anotherValue) {
if (anotherValue == this.anotherValue) {
return;
}
isInitialised = false; // Calculated value is now invalid
this.anotherValue = anotherValue;
}
/**
* This is where the time expensive stuff is done.
*/
public void init() {
if (isInitialised) {
return;
}
/* In reality this is some very costly process that I don't want to run often,
* probably run in another thread */
calculatedValue = someValue * anotherValue;
isInitialised = true;
}
/**
* Only valid if initialised
*/
public double getCalculatedValue() {
init();
return calculatedValue;
}
/**
* Code for testing
*/
public static void main(String[] args) {
BeanTest myBean = new BeanTest();
myBean.setSomeValue(3);
myBean.setAnotherValue(2);
System.out.println("Calculated value: " + myBean.getCalculatedValue());
}
}
This approach has multiple issues. For example, it doesn't extend well (and some of these really are intended to be extended). Also, I show only a simple case here with three variables; the real classes have many more. Things are becoming a mess.
Can anybody suggest a different method or pattern that could help me keep the code more elegant and readable and still allow things to work as expected in a GUI builder please?
P.S.
This is meant to be mutable.
EDITED
I think by trivialising I hid the point a bit.
The trick is I want to run the init() stuff only once, and only when everything is set. If I was using a builder pattern, this would be easy, as I would put it in the build() method, but this is in a GUI element and so is in a JavaBean pattern.
The code I have above is a trivialised version of the "pattern" I am using. The pattern does work, but there are many weaknesses as I have noted, particularly with extensability (is that a word?) and as the number of variables grows. The trivial example looks alright, but the real code is starting to look horrendous.
I guess this could just be a weakness of the JavaBean pattern, but I thought I'd ask before I crafted another dozen dodgy classes in my package.

Naive approach: why not simply call init() in the setter instead?
A bit more fancy: use a PropertyChangeSupport object. Sample usage:
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;
public class TestBean implements PropertyChangeListener{
private int someValue;
private PropertyChangeSupport changeSupport;
public TestBean() {
changeSupport = new PropertyChangeSupport(this);
changeSupport.addPropertyChangeListener(this);
}
private void init() {
//do something time consuming, maybe even on a different thread, using Futures?
}
#Override
public void propertyChange(PropertyChangeEvent evt) {
init();
}
public int getSomeValue() {
return someValue;
}
public void setSomeValue(int someValue) {
int oldValue = this.someValue;
this.someValue = someValue;
changeSupport.firePropertyChange("someValue", oldValue, someValue);
}
}

I think I have to accept that what I'm trying to achieve can't be done. Here is a quote from Bloch's "Effective Java":
Unfortunately, the JavaBeans pattern has serious disadvantages of its
own. Because construction is split across multiple calls, a JavaBean
may be in an inconsistent state partway through its construction. The
class does not have the option of enforcing consistency merely by
checking the validity of the constructor parameters.
While it doesn't exactly answer my question, I think any answer that gets around the isInitialized variable would run into the issue that Bloch describes.

Template Variables in Eclipse - var()

I'm developing an Eclipse plugin for a C dialect. Currently I'm working on Content Assist and I want to introduce templates for most common language constructs.
In my work I was following this tutorial:
I would like to take advantages of templates (specified e.g. here) such as: ${id:var(type[,type]*)}, for example to provide template for function call with completion proposals for each function parameter but filtered out to show only proposals of compatible type. Unfortunately I'm not able to find any relevant tutorials or examples.
I would be grateful for any suggestion, links, code snippets, etc.
Thanks in advance!
Grzegorz

By trial and error I've finally managed to provide such completion proposals. I will explain it briefly but I do not guarantee that this is the right way, but it works :)
If we have a function foo(boolean bar, boolean baz) we can create corresponding template: foo(${bar:var(boolean)}, ${baz:var(boolean)}). To handle such template we can register custom TemplateVariableResolver:
public final class VariableResolver extends TemplateVariableResolver {
public VariableResolver() {
super("var", "some description");
}
#Override
public void resolve(TemplateVariable variable, TemplateContext context) {
final String name = variable.getName(); /* bar or baz */
final List params = variable.getVariableType().getParams(); /* ["boolean"] */
variable.setValues(computeSuggestions(name, params));
variable.setResolved(true);
}
private String[] computeSuggestions(String name, List params) {
return new String[] {"true", "false"};
// TODO: more sophisticated proposals
}
// overwrite other methods!
}
The next step is to make your CompletionProcessor extend TempateCompletionProcessor.
Here is a (simplified) default implementation of computeCompletionProposals() in TemplateCompletionProcessor
public ICompletionProposal[] computeCompletionProposals(ITextViewer viewer, int offset) {
/* some code */
TemplateContext context= createContext(viewer, region);
if (context == null)
return new ICompletionProposal[0];
context.setVariable("selection", selection.getText()); // name of the selection variables {line, word}_selection //$NON-NLS-1$
Template[] templates= getTemplates(context.getContextType().getId());
/* some code */
return (ICompletionProposal[]) matches.toArray(new ICompletionProposal[matches.size()]);
}
Then VariableResolver should be registered in computeCompletionProposalsor somewhere else:
context.getContextType().addResolver(new VariableResolver());
Therefore if getTemplates() will return our exemplary template and user will use it, for parameters bar and baz resolve() will be called, so that we can provide proposals for each foo function parameters with regard to these parameter types.

Logging framework for the java application

I have created a small web application in java. And now I want to add Logging features to it. But i don't want to use any available Logging framework like Log4j or something else, instead I want to create my own logging framework which can be expendable in future as well. So need some initial push ups for the same, And this is the right place for that.
Thanks.

My advice would be not to do it. Use tried and tested logging frameworks such as log4j. Why do you want to reinvent the wheel?
A lot of time has been spent on existing frameworks - making them work fast, under various different environments etc. Do you really want to waste time replicating that effort when you could spend the same time on features that your users will really care about?
Don't forget that many frameworks (such as log4j, or even the built-in java.util.logging) are extensible with your own formatters, handlers etc. You should really work out what you want to do which isn't covered by the existing frameworks and see whether you can build just that bit rather than creating yet another logging framework.
If and when you've worked out that you do need to write some extra code, you can then ask questions about those specific needs, rather than your current rather general question.

It's a good thing to do only because you'll realise why you should use one of the many and excellent logging frameworks. After you have fiddled around with this for a week, go back and use log4j.
However, until then, and to get you started, here is one I prepared earlier just because I wanted to get my head round what the complexity was. This is incomplete for your purposes and I recommend you use it just to decide what you want to do rather than base your implementation on it. It should give you a reasonable idea of what is necessary and it provides basic single threaded logging...
/*
* Created on Jun 11, 2005
*/
package com.hupa.util;
import java.io.*;
import java.util.Date;
/**
* #author simonpalmer
*/
public class MessageWriter implements ILog
{
public class e_LogLevel
{
public static final int e_log_error = 1;
public static final int e_log_warn = 2;
public static final int e_log_info = 4;
public static final int e_log_debug = 8;
}
public int m_iLogLevel = e_LogLevel.e_log_error;
public String m_strLogFile = new String();
public String m_strLogPath = new String();
public boolean m_bConsoleOut = true;
PrintStream m_ps;
public boolean m_bLogOpen = false;
private static Date dt = new Date();
/**
* Output info level message
* #param strMess
*/
public void info(String strMess)
{
if ((m_iLogLevel & e_LogLevel.e_log_info) == e_LogLevel.e_log_info)
{
dt.setTime(System.currentTimeMillis());
String strOut = dt.toString() + " inf: " + strMess;
if (m_bConsoleOut) System.out.println(strOut);
if (m_bLogOpen) m_ps.println(strOut);
}
}
public boolean bInfo(){return ((m_iLogLevel & e_LogLevel.e_log_info) == e_LogLevel.e_log_info);}
/**
* Output debug level message
* #param strMess
*/
public void debug(String strMess)
{
if ((m_iLogLevel & e_LogLevel.e_log_debug) == e_LogLevel.e_log_debug)
{
dt.setTime(System.currentTimeMillis());
String strOut = dt.toString() + " dbg: " + strMess;
if (m_bConsoleOut) System.out.println(strOut);
if (m_bLogOpen) m_ps.println(strOut);
}
}
public boolean bDebug(){return ((m_iLogLevel & e_LogLevel.e_log_debug) == e_LogLevel.e_log_debug);}
/**
* Output warning level message
* #param strMess
*/
public void warn(String strMess)
{
if ((m_iLogLevel & e_LogLevel.e_log_warn) == e_LogLevel.e_log_warn)
{
dt.setTime(System.currentTimeMillis());
String strOut = dt.toString() + " warn: " + strMess;
if (m_bConsoleOut) System.out.println(strOut);
if (m_bLogOpen) m_ps.println(strOut);
}
}
public boolean bWarn(){return ((m_iLogLevel & e_LogLevel.e_log_warn) == e_LogLevel.e_log_warn);}
/**
* Output error level message
* #param strMess
*/
public void error(String strMess)
{
if ((m_iLogLevel & e_LogLevel.e_log_error) == e_LogLevel.e_log_error)
{
dt.setTime(System.currentTimeMillis());
String strOut = dt.toString() + " err: " + strMess;
if (m_bConsoleOut) System.out.println(strOut);
if (m_bLogOpen) m_ps.println(strOut);
}
}
public boolean bError(){return ((m_iLogLevel & e_LogLevel.e_log_error) == e_LogLevel.e_log_error);}
/**
* construst the log file name
* #return String, full file path and name
*/
public String GetLogFileName()
{
return m_strLogPath + m_strLogFile + ".log";
}
/**
* Open the log file prescribed by the settings
* #return boolean, success
*/
public boolean OpenLog()
{
try
{
m_ps = new PrintStream(new FileOutputStream(GetLogFileName()));
m_bLogOpen = true;
}
catch (FileNotFoundException e)
{
// this means that the folder doesn't exist
if (MakeFolder(m_strLogPath))
{
m_bLogOpen = true;
try
{
m_ps = new PrintStream(new FileOutputStream(GetLogFileName()));
}
catch (IOException e1)
{
e.printStackTrace();
m_bLogOpen = false;
}
}
}
return m_bLogOpen;
}
public static boolean MakeFolder(String strFolder)
{
try
{
java.io.File f = new File(strFolder);
if (!f.mkdirs())
{
return false;
}
}
catch (SecurityException e)
{
e.printStackTrace();
return false;
}
return true;
}
/**
* Close the log file
* #return boolean, success
*/
public boolean CloseLog()
{
if (m_ps != null)
{
m_ps.flush();
m_ps.close();
}
m_bLogOpen = false;
return m_bLogOpen;
}
public void setConsoleOut(boolean b)
{
m_bConsoleOut = b;
}
public void setLogLevel(int i)
{
m_iLogLevel = i;
}
}
and here's the interface
public interface ILog
{
abstract public void debug(String message);
abstract public void info(String message);
abstract public void warn(String message);
abstract public void error(String message);
abstract public void setLogLevel(int i);
abstract public void setConsoleOut(boolean b);
abstract public boolean CloseLog();
abstract public boolean OpenLog();
abstract public boolean bDebug();
}

These are some pitfalls you may fell in while trying to create your own logging framework:
Concurrency issues: The logging framework may be accessed at the same time by different threads. You need to ensure that no conflicts arise and that the messages are logged in the right order.
Instantiation: The framework must be instantiated once and then be available to the rest of the application. You need a 'Singleton' class, which you must implement carefully. Using static methods is a way to go.
You must have a configuration mechanism, using xml files or annotations.
Your framework must cooperate with third-party libraries. I believe this is the real stopper for you. You may have your logging framework for your code, but the libraries you are using require another one.

If you really want to make your own logging franmework (and I strongly suggest you dont), then write down some requirements first. What should it do? What features should it have etc.
Examples are the ability to write to mulitple outputs - files, consoles, sockets, serial ports etc
Also multithreaded writing - you dont want multiple threads writing to a log at the same time, else you'll end up with garbage.
Log levels - how many?
Then you can start writing code....only, as suggested, I dont see why you're not using one of the many freely available logging framewroks out there,,,

There are already too many Java logging frameworks out there.
Why not just wrap the built in java.util.logging?
https://docs.oracle.com/javase/8/docs/technotes/guides/logging/overview.html

You want a small memory footprint yet expandability? Avoid premature optimization, then: try log4j or java.util.logging, measure the footprint (conditional compilation), and see if you really can beat that by rolling your own or branching off. Besides defining requirements as Visage advises, and meeting the pitfalls kgiannakakis points out, measurements are your best friend.