I have been trying for the past few hours to get the following functionality working.
public class OMG {
String name;
HashMap<SETTINGS, String> settings;
public enum SETTINGS {
Setting1("OMG setting 1"), Setting2("OMG setting 2");
private String key;
#Override
public String toString() {
return "SETTINGS: " + key;
}
SETTINGS(String key){
this.key = key;
}
}
public OMG(String name, HashMap<SETTINGS, String> settings) {
this.name = name;
this.settings = settings;
}
}
and
public class Test {
public static void main(String[] args) {
try {
Class<?> c = Class.forName("path.to.OMG" + "$" + "SETTINGS");
System.out.println(Arrays.toString(c.getEnumConstants()));
HashMap<c,String > values = new HashMap<>();
OMG omg = new OMG("blah",values);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
I have to create an OMG instance and am been given the path to OMG and the enum NAME. So far I have the code in the Test class. I am able to get all enumValues however I have no idea how to create a HashMap and how to call the constructor with this HashMap to get an instance of the OMG class.
Please help.
Thank you
There is no practical reason for doing what you are trying to do. The way to instantiate an OMG is to do new OMG("foo", new HashMap<SETTINGS, String>());
However, as a purely academic exercise (I like these!), let's see if we can instantiate an OMG only using class names given as strings and without actually typing OMG or SETTINGS anywhere. It can be done!
In Java, generics are a compile-time feature only. At runtime, a HashMap<SETTINGS, String> is no different from a HashMap<Double, Float> or a raw HashMap. Therefore you can instantiate any old HashMap - there is no need to use the object c at all (and you can't use a Class object as a type parameter liken this anyway).
Here is a solution:
public static void main(String[] args) throws Exception {
Class<?> clazz = Class.forName("path.to.OMG");
Constructor constructor = clazz.getConstructor(String.class, HashMap.class);
Object omgInstance = constructor.newInstance("foo", new HashMap<Void, Void>());
System.out.println(omgInstance.getClass()); // OMG - it worked!
}
From your own answer, I read that you want to use enum entries as keys and default values for the actual configuration that is stored in the map in the class OMG. This configuration should also be written to a file.
Now, you have to make a design decision: When do you want to be able to change which configuration keys can be used and/or the default values? While the program is already running (at run-time) or when the program is recompiled (at compile-time)?
Your description suggests that you want to be able to change them at run-time. Is this correct? Also, is this really needed? Your existing code will probably not use values which are provided for the new keys. Also, a changed default value will probably not have an effect, since the value was already initialized using the old default value.
If you really want to change these information at run-time, then you should not use an enum to store and load them. While this style of programming might work in scripting languages like JavaScript, it does not work well in Java. An enum, like any other code is not supposed to be changed at run-time, but it should be given at compile-time.
Since in Java the code is not supposed to be changed at run-time, the JVM does not even allow to simply reload a class, without doing some class loader magic. You normally want to avoid this whenever possible. For more information about this, see here. It is not impossible to reload a class at run-time, but it is definitely the wrong solution to the problem that you are facing.
So, what is a correct solution? I am still not convinced that you really need to change the information at run-time. If this is correct and you only need to change the information at compile-time, you can simply use your current enum approach. However, you can simplify it to not load the class by name, please see below for more details about a possible implementation.
If you really need to be able to change the information at run-time, you should not store the information in the code, but in a file. This enables you to easily reload the information by re-reading the file. You can use a properties file, which is common in the Java world, see here. If you need a more structured file format, you can use a JSON file. In Java, you can use Gson to work with JSON files, see here.
This works for me:
package test;
import java.util.Arrays;
import java.util.EnumMap;
public class Test {
public static enum SETTINGS {
Setting1("OMG setting 1"), Setting2("OMG setting 2");
private String key;
#Override
public String toString() {
return "SETTINGS: " + key;
}
SETTINGS(String key) {
this.key = key;
}
}
public static class OMG<E extends Enum<E>> {
String name;
EnumMap<E, String> settings;
public OMG(String name, EnumMap<E, String> settings) {
this.name = name;
this.settings = settings;
}
public static <E extends Enum<E>> OMG<E> create(String name,
Class<E> enumClass) {
return new OMG<E>(name, new EnumMap<E, String>(enumClass));
}
}
public static void main(String[] args) {
try {
Class c = Class.forName("test.Test$SETTINGS");
// alternatively you can use:
// Class<SETTINGS> c = SETTINGS.class;
System.out.println(Arrays.toString(c.getEnumConstants()));
OMG.create("foobar", c);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
I assumed that you want to pass any enum type to the class OMG and not only SETTINGS. If it should only be SETTINGS, you might as well just use SETTINGS directly in your code. This is why I moved the SETTINGS enum out of the OMG class.
Next, I added a generic type parameter E to the class OMG, so OMG does not directly depend on SETTINGS. To enable easier initialization, I added a static factory method to OMG, which also uses a generic type parameter E. It only receives the name and the class objects which matches E. You need the class objects, since in Java you cannot directly use the generic type parameters for reflection.
Also, I replaced the HashMap by an EnumMap, since EnumMap is an optimized map implementation when the key is an enum.
Finally, the initialization of the OMG class: If you really need to create the class object from the name of the class, using reflection, you can use the code as is. Note that this will produce a warning. However, most of the time you want to use the class objects directly, like in the commented line of code. If you use this second method, you will not get a warning and you can also omit the try-catch block.
Thanks to #PaulBoddington I solved the issue as follows.
public class Test {
public static void main(String[] args) {
try {
Class<?> c = Class.forName("path.to.OMG" + "$" + "SETTINGS");
Object[] enumConstants = c.getEnumConstants();
HashMap<Object, String > configuration = new HashMap<>();
for (Object enumConstant: enumConstants){
configuration.put(enumConstant, enumConstant.key);
}
OMG omg = new OMG("blah", configuration);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
The use case for people wondering is that OMG is a module in the system which is configurable and also has to allow from a developers point of view new settings to be added easily. This is why settings and their value is kept in a HashMap < SETTING , STRING > and SETTING is an enum containing the key in the configuration file under which the setting should be found as well as other information - default value of example. The OMG class also has a
String getSettingValue(SETTING setting){
return settingsMap.get(setting);
}
method which returns the value for a setting and is what is exposed by the module.
This means that if a new setting has to be added to the component I just have to create a new instance of the SETTINGS enum and thats it. During creation if the server has not send a value for this setting I can either use the default or crash. On the other hand once the component is instantiated I have immediate access to the new setting without touching the existing code.
Please share your opinion on this architecture couse it is for a school project and I highly doubt the teacher will actually look into it and tell me if it is reasonable or not.
Thank you
Related
I want to ask about nested enums. I am working with old code and i found very strange construction that i not really good understand.
I have this enum :
public enum DbEngines {
ORACLE("oracle", "set define on", "set define off")
, POSTGRESQL("postgresql", "--TODO set define on", "--TODO set define off");
private final String dbEngine;
private String setOn;
private String setOff;
DbEngines(String dbEngine, String setOn, String setOff) {
this.dbEngine = dbEngine;
this.setOn = setOn;
this.setOff = setOff;
}
public String getSetOn() {
return setOn;
}
public String getSetOff() {
return setOff;
}
public String toString() {
return this.dbEngine;
}
}
I added private String to this enum, that are engine specific, so it is good place for me here. The problem is, that in some places in method declaration i see something like that
public someMethod(Enum<DbEngines> engine, ...)
And it worked perfectly without methods, but now, after changing, I couldn't call public getters of this enum. But if i change to :
public someMethod(DbEngines engine, ...)
it works without any problems with all public getters. Maybe someone could explain that?
Enum in Java is the base class for all enumeration types. One can think of it as similar to Object class.
Just like one can hold reference of object of any class using the reference of type Object, one can refer to an enumeration type using the reference of type Enum.
Object o = new Integer(10);
Enum e = DBEngine.ORACLE;
One cannot invoke a method present in inherited class but absent in superclass using the reference of superclass.
Similar explanation over here.
I am creating a store for user preferences, and there are a fixed number of preferences that users can set values for. The names of the preferences (settings) are stored as an Enum:
public enum UserSettingName {
FOO,
BAR,
ETC
}
What I would like to be able to do is store a value type with the name so that the service will store the user's value with the correct Java type. For example, FOO might be a Long, and BAR might be a String. Up until now, we were storing all values as Strings, and then manually casting the values into the appropriate Java type. This has lead to try/catch blocks everywhere, when it makes more sense to have only one try/catch in the service. I understand that Enums cannot have generic types, so I have been playing around with:
public enum UserSettingName {
FOO(Long.class),
BAR(String.class),
ETC(Baz.class)
private Class type;
private UserSettingName(Class type) {
this.type = type;
}
public Class getType() {
return this.type;
}
}
I have a generic UserSetting object that has public T getSettingValue() and public void setSettingValue(T value) methods that should return and set the value with the correct type. My problem comes from trying to specify that generic type T when I create or retrieve a setting because I can't do something like:
new UserSetting<UserSettingName.FOO.getType()>(UserSettingName.FOO, 123L)
Sorry if this isn't exactly clear, I can try to clarify if it's not understood.
Thanks!
UPDATE
Both the setting name and value are coming in from a Spring MVC REST call:
public ResponseEntity<String> save(#PathVariable Long userId, #PathVariable UserSettingName settingName, #RequestBody String settingValue)
So I used the Enum because Spring casts the incoming data automatically.
Firstly you have to step back and think about what you're trying to achieve, and use a standard pattern or language construct to achieve it.
It's not entirely clear what you're going after here but from your approach it almost certainly looks like you're reinventing something which could be done in a much more straightforward manner in Java. For example, if you really need to know and work with the runtime classes of objects, consider using the reflection API.
On a more practical level - what you're trying to do here isn't possible with generics. Generics are a compile-time language feature - they are useful for avoiding casting everything explicitly from Object and give you type-checking at compilation time. You simply cannot use generics in this way, i.e. setting T as some value UserSettingName.Foo.getType() which is only known at runtime.
Look how it done by netty:
http://netty.io/wiki/new-and-noteworthy.html#type-safe-channeloption
They done it by using typed constants:
http://grepcode.com/file/repo1.maven.org/maven2/io.netty/netty-all/4.0.0.Beta1/io/netty/channel/ChannelOption.java#ChannelOption
EDIT:
public interface ChannelConfig {
...
<T> boolean setOption(ChannelOption<T> option, T value);
...
}
public class ChannelOption<T> ...
public static final ChannelOption<Integer> SO_TIMEOUT =
new ChannelOption<Integer>("SO_TIMEOUT");
...
}
EDIT2: you can transform it like:
class Baz {}
class UserSettingName<T> {
public static final UserSettingName<Baz> ETC = new UserSettingName<Baz>();
}
class UserSetting {
public <T> UserSetting(UserSettingName<T> name, T param) {
}
}
public class Test {
public static void main(String[] args) {
new UserSetting(UserSettingName.ETC, new Baz());
}
}
Enums are not the answer here. If you find yourself repeating code everywhere you could just create a utility class and encapsulate all the try/catch logic there. That would cut down on your code redundancy without majorly impacting your current code.
public class Util
{
public static MyObject getObjectFromString(String s)
{
try
{
return (MyObject)s;
}
catch(Exception e)
{
return null;
}
}
}
Then use as follows:
MyObject myObj = Util.getObjectFromString(string);
I have a parser class "MessageParser" which i pass a message which is of type "String" to it for it to be parsed. The parsing method signature for the class is
public void parse(String message);
I need to pass an instance of "Properties" to it but i dont want to change the signature of the method to add a new argument to it. I have been struggling with this for the last couple of days and have tried a couple of options - see Sending in an object of type Object instead of String - Polymorphism
The class that calls the parsing method "ParserManager" knows of the properties object. Is there a way for the MessageParser to find the properties object without it being passed to it?
Edit
Here is some example code.
I would like the "MessageCparser" to access the "prop" object in "ParserManager" without changing anything in the "Parser" interface or the "ParserManager" class. Is this possible?
public interface Parser{
public void parse(String message);
}
public class MessageCParser implements Parser{
public void parse(String message){
MessageObject mobject = (MessageObject)message;
System.out.println("Parsing C" + mobject.getMessage());
}
public void parse(String m){}
}
import java.util.HashMap;
public class ParserManager{
Properties prop = null;
public ParserManager() {
prepare();
prop = new Properties()
}
HashMap parsers = new HashMap();
public void prepare(){
parsers.put("A",new MessageCParser());
}
public void parseMessage(String msgType, String message){
((Parser)parsers.get(msgType)).parse(message);
}
}
Thanks
The most evident solution would be to add a reference to the Properties object as a field in the ParserManager, and then either provide the ParserManager with the properties object as a constructor argument or through a setter-method as shown below:
class ParserManager {
...
Properties props;
public void setParsingProperties(Properties props) {
this.props = props;
}
public void parse(String message) {
// props available here, without being passed as agurment.
}
}
class CallingParserManager {
...
void someMethod() {
...
parserManager.setParsingProperties(propertiesToUse);
parserManager.parse(theString);
...
}
...
}
Looking at your previous question, I'd say it would be fine if you added a setParsingProperties in the Parser interface. The method can be implemented as an empty method for those parser that don't need the properties.
Regarding your edit: No, it's not possible to solve it like that.
MessageObject mobject = (MessageObject) message;
Will only work if MessageObject is a subtype of String (but since String is final (can't be extended) that cannot be the case).
The dirty quick-fix would be to check (with instanceof) if the Parser is an instance of MessageCParser and cast it and then use a MessageCParser specific parse method that takes the Properties as an argument.
Well, there are four ways of getting information, broadly speaking:
It could be part of the state of the object that the method is called on (e.g. it could be passed to the constructor and then retained in a field)
It can be a parameter of the method itself
It could be accessed statically, e.g. via a singleton
It could be accessed via a thread-local variable
All of these can be used with indirection of course - for example, if something else which knows about the Properties is available via one of the above mechanisms, then you can get to that and then find out about the Properties. But you can't just find out the calling object and ask that.
What do you need to do with the Properties in question? Would the Properties vary on a call-by-call basis for the same MessageParser? If so, it really should be a parameter. You say you don't want to change the signature of the method - but if you want to pass more information in, that's exactly what you should do.
If you have only one instance of your "Properties" object, you can use something like the Singleton pattern.
You can also add a reference to the ParserManager somewhere in your MessageParser and then call a method on ParserManager which will return the Properties, but without some code snippets it's impossible to help you further than this.
First of all I should probably say that the term 'constant object' is probably not quite right and might already mean something completely different from what I am thinking of, but it is the best term I can think of to describe what I am talking about.
So basically I am designing an application and I have come across something that seems like there is probably an existing design pattern for but I don't know what it is or what to search for, so I am going to describe what it is I am trying to do and I am looking for suggestions as to the best way to implement it.
Lets say you have a class:
public class MyClass {
private String name;
private String description;
private int value;
public MyClass(String name, String description, int value) {
this.name = name;
this.description = description;
this.value = value;
}
// And I guess some getters and setters here.
}
Now lets say that you know in advance that there will only ever be say 3 instances of this class, and the data is also known in advance (or at least will be read from a file at runtime, and the exact filename is known in advance). Basically what I am getting at is that the data is not going to be changed during runtime (once it has been set).
At first I thought that I should declare some static constants somewhere, e.g.
public static final String INSTANCE_1_DATA_FILE = "path/to/instance1/file";
public static final String INSTANCE_2_DATA_FILE = "path/to/instance2/file";
public static final String INSTANCE_3_DATA_FILE = "path/to/instance3/file";
public static final MyClass INSTANCE_1 = new MyClass(getNameFromFile(INSTANCE_1_DATA_FILE), getDescriptionFromFile(INSTANCE_1_DATA_FILE), getValueFromFile(INSTANCE_1_DATA_FILE));
public static final MyClass INSTANCE_2 = new MyClass(getNameFromFile(INSTANCE_2_DATA_FILE), getDescriptionFromFile(INSTANCE_2_DATA_FILE), getValueFromFile(INSTANCE_2_DATA_FILE));
public static final MyClass INSTANCE_3 = new MyClass(getNameFromFile(INSTANCE_3_DATA_FILE), getDescriptionFromFile(INSTANCE_3_DATA_FILE), getValueFromFile(INSTANCE_3_DATA_FILE));
Obvisouly now, whenever I want to use one of the 3 instances I can just refer directly to the constants.
But I started thinking that there might be a cleaner way to handle this and the next thing I thought about was doing something like:
public MyClassInstance1 extends MyClass {
private static final String FILE_NAME = "path/to/instance1/file";
public String getName() {
if (name == null) {
name = getNameFromFile(FILE_NAME);
}
return name;
}
// etc.
}
Now whenever I want to use the instances of MyClass I can just use the one I want e.g.
private MyClass myInstance = new MyClassInstance2();
Or probably even better would be to make them singletons and just do:
private MyClass myInstance = MyClassInstance3.getInstance();
But I can't help but think that this is also not the right way to handle this situation. Am I overthinking the problem? Should I just have a switch statement somewhere e.g.
public class MyClass {
public enum Instance { ONE, TWO, THREE }
public static String getName(Instance instance) {
switch(instance) {
case ONE:
return getNameFromFile(INSTANCE_1_DATA_FILE);
break;
case TWO:
etc.
}
}
}
Can anyone tell me the best way to implement this? Note that I have written the sample code in Java because that is my strongest language, but I will probably be implementing the application in C++, so at the moment I am more looking for language independent design patterns (or just for someone to tell me to go with one of the simple solutions I have already mentioned).
If you want the values to be constant, then you will not need setters, otherwise code can simply change the values in your constants, making them not very constant. In C++, you can just declare the instances const, although I'd still get rid of the setters, since someone could always cast away the const.
The pattern looks ok, although the fact that you are creating a new instance each time one is requested, is not usual for constants.
In java, you can create enums that are "smart" e.g.
public enum MyClass {
ONE(INSTANCE_1_DATA_FILE),
TWO(INSTANCE_2_DATA_FILE),
//etc...
private MyClass(String dataFile)
{
this(getNameFromDataFile(dataFile), other values...)
}
private MyClass(String name, String data, etc...)
{
this.name = name;
// etc..
}
public String getName()
{
return name;
}
}
In C++, you would create your MyClass, with a private constructor that takes the filename and whatever else it needs to initialize, and create static const members in MyClass for each instance, with the values assigned a new instance of MyClass created using the private constructor.
EDIT: But now I see the scenario I don't think this is a good idea having static values. If the types of ActivityLevel are fundamental to your application, then you can enumerate the different type of activity level as constants, e.g. a java or string enum, but they are just placeholders. The actual ActivityDescription instances should come from a data access layer or provider of some kind.
e.g.
enum ActivityLevel { LOW, MED, HIGH }
class ActivityDescription
{
String name;
String otherDetails;
String description; // etc..
// perhaps also
// ActivityLevel activityLevel;
// constructor and getters
// this is an immutable value object
}
interface ActivityDescriptionProvider
{
ActivityDescription getDescription(ActivityLevel activityLevel);
}
You can implement the provider using statics if you want, or an enum of ActivityDescription instnaces, or better still a Map of ActivityLevel to ActivityDescription that you load from a file, fetch from spring config etc. The main point is that using an interface to fetch the actual description for a given ActivityLevel decouples your application code from the mechanics of how those descriptions are produced in the system. It also makes it possible to mock the implementation of the interface when testing the UI. You can stress the UI with a mock implementation in ways that is not possible with a fixed static data set.
Now lets say that you know in advance that there will only ever be say 3 instances of this class, and the data is also known in advance (or at least will be read from a file at runtime, and the exact filename is known in advance). Basically what I am getting at is that the data is not going to be changed during runtime (once it has been set).
I'd use an enum. And then rather in this flavor:
public enum MyEnum {
ONE("path/to/instance1/file"),
TWO("path/to/instance2/file"),
THREE("path/to/instance3/file");
private String name;
private MyEnum(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
Which can be used as follows:
MyEnum one = MyEnum.ONE;
String name = one.getName();
(I'm too slow once again, you already accepted an answer, but here it is anyway...)
You want to (a) prevent changes to the data held in objects of MyClass, and (b) allow only a fixed set of MyClass objects to exist, implying that runtime code should not be able to create new instances of MyClass.
Your initial example has a public constructor, which violates (b)
I'd use a Factory approach so the Factory is the only thing that can create instances, and the class doesn't provide any setters so it's immutable.
Depending on how much flexibility you want for the future, you could put the factory and the class in the same package and limit scope that way, or you could make MyClass an inner class within the factory. You may also consider making MyClass an interface separate from its implementation.
A properties file could be used to configure the factory itself.
The properties file (e.g. "foo.properties") could look something like
one=/path/to/datafile1
two=/another/path/to/datafile2
three=/path/to/datafile3
I use "Foo" instead of "MyClass" in the (Java) examples below.
public class FooFactory
{
/** A place to hold the only existing instances of the class */
private final Map<String, Foo> instances = new HashMap<String, Foo>();
/** Creates a factory to manufacture Foo objects */
// I'm using 'configFile' as the name of a properties file,
// but this could use a Properties object, or a File object.
public FooFactory(String configfile)
{
Properties p = new Properties();
InputStream in = this.getClass().getResourceAsStream();
p.load(in); // ignoring the fact that IOExceptions can be thrown
// Create all the objects as specified in the factory properties
for (String key : p.keys())
{
String datafile = p.getProperty(key);
Foo obj = new Foo(datafile);
instances.put(key, obj);
}
}
public Foo getFoo(String which)
{
return instances.get(which);
}
/** The objects handed out by the factory - your "MyClass" */
public class Foo
{
private String name;
private String description;
private int value;
private Foo(String datafile)
{
// read the datafile to set name, description, and value
}
}
}
You're set to allow only your predefined instances, which can't be changed at runtime, but you can set it all up differently for another run at a later time.
Your first method seems to me like the best and the least prone to code rot. I'm not impressed by the idea of subclassing an object just to change the file name that contains the data that will be used to build it.
Of course, you could maybe improve on your original idea by wrapping these all in an outer class that provides some sort of enumeration access. A collection of MyClass's in other words. But I think you should discard this subclassing idea.
First, you really should be limiting where you use these instances in the code. Use them in as few places as possible. Given these are file names, I expect you want three class instances which accesses the files. How many classes are required depends on what your want to do with them? Look at the Singleton pattern for these classes.
Now you don't need the constants, but could have a helper class which will read the file containing the file names and supply them to the reader class. The code to find then name could also be a method called by the static initializer of the Singleton.
The common approach is to use a map:
private static final Map<String, YouClass> mapIt =
new HashMap<String, YouClass>(){{
put("one", new YourClass("/name", "desc", 1 )),
put("two", new YourClass("/name/two", "desc2", 2 )),
put("three", new YourClass("/name/three", "desc", 3 ))
}}
public static YourClass getInstance( String named ) {
return mapIt.get( named );
}
Next time you need it:
YouClass toUse = YourClass.getInstance("one");
Probably using strings as keys is not the best option but you get the idea.
I have a poorly designed class in a 3rd-party JAR and I need to access one of its private fields. For example,
why should I need to choose private field is it necessary?
class IWasDesignedPoorly {
private Hashtable stuffIWant;
}
IWasDesignedPoorly obj = ...;
How can I use reflection to get the value of stuffIWant?
In order to access private fields, you need to get them from the class's declared fields and then make them accessible:
Field f = obj.getClass().getDeclaredField("stuffIWant"); //NoSuchFieldException
f.setAccessible(true);
Hashtable iWantThis = (Hashtable) f.get(obj); //IllegalAccessException
EDIT: as has been commented by aperkins, both accessing the field, setting it as accessible and retrieving the value can throw Exceptions, although the only checked exceptions you need to be mindful of are commented above.
The NoSuchFieldException would be thrown if you asked for a field by a name which did not correspond to a declared field.
obj.getClass().getDeclaredField("misspelled"); //will throw NoSuchFieldException
The IllegalAccessException would be thrown if the field was not accessible (for example, if it is private and has not been made accessible via missing out the f.setAccessible(true) line.
The RuntimeExceptions which may be thrown are either SecurityExceptions (if the JVM's SecurityManager will not allow you to change a field's accessibility), or IllegalArgumentExceptions, if you try and access the field on an object not of the field's class's type:
f.get("BOB"); //will throw IllegalArgumentException, as String is of the wrong type
Try FieldUtils from Apache commons-lang3:
FieldUtils.readField(object, fieldName, true);
P.S. In my opinion, reflection is evil.
Reflection isn't the only way to resolve your issue (which is to access the private functionality/behaviour of a class/component)
An alternative solution is to extract the class from the .jar, decompile it using (say) Jode or Jad, change the field (or add an accessor), and recompile it against the original .jar. Then put the new .class ahead of the .jar in the classpath, or reinsert it in the .jar. (the jar utility allows you to extract and reinsert to an existing .jar)
As noted below, this resolves the wider issue of accessing/changing private state rather than simply accessing/changing a field.
This requires the .jar not to be signed, of course.
One other option that hasn't been mentioned yet: use Groovy. Groovy allows you to access private instance variables as a side effect of the design of the language. Whether or not you have a getter for the field, you can just use
def obj = new IWasDesignedPoorly()
def hashTable = obj.getStuffIWant()
Using the Reflection in Java you can access all the private/public fields and methods of one class to another .But as per the Oracle documentation in the section drawbacks they recommended that :
"Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform"
here is following code snapts to demonstrate basic concepts of Reflection
Reflection1.java
public class Reflection1{
private int i = 10;
public void methoda()
{
System.out.println("method1");
}
public void methodb()
{
System.out.println("method2");
}
public void methodc()
{
System.out.println("method3");
}
}
Reflection2.java
import java.lang.reflect.Field;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;
public class Reflection2{
public static void main(String ar[]) throws IllegalAccessException, IllegalArgumentException, InvocationTargetException
{
Method[] mthd = Reflection1.class.getMethods(); // for axis the methods
Field[] fld = Reflection1.class.getDeclaredFields(); // for axis the fields
// Loop for get all the methods in class
for(Method mthd1:mthd)
{
System.out.println("method :"+mthd1.getName());
System.out.println("parametes :"+mthd1.getReturnType());
}
// Loop for get all the Field in class
for(Field fld1:fld)
{
fld1.setAccessible(true);
System.out.println("field :"+fld1.getName());
System.out.println("type :"+fld1.getType());
System.out.println("value :"+fld1.getInt(new Reflaction1()));
}
}
}
Hope it will help.
As oxbow_lakes mentions, you can use reflection to get around the access restrictions (assuming your SecurityManager will let you).
That said, if this class is so badly designed that it makes you resort to such hackery, maybe you should look for an alternative. Sure this little hack might be saving you a few hours now, but how much will it cost you down the road?
Java 9 introduced Variable Handles. You can access a private field of a class using them.
The code for your example will look like following:
var lookup = MethodHandles.lookup();
var handle = MethodHandles
.privateLookupIn(IWasDesignedPoorly.class, lookup)
.findVarHandle(IWasDesignedPoorly.class, "stuffIWant", Hashtable.class);
var value = handle.get(obj);
It is also advisable to use Lookup and VarHandle objects as static final fields.
Use the Soot Java Optimization framework to directly modify the bytecode.
http://www.sable.mcgill.ca/soot/
Soot is completely written in Java and works with new Java versions.
If using Spring:
In a testing context, ReflectionTestUtils provides some handy tools that can help out here with minimal effort. It's described as being "for use in unit and integration testing scenarios".
In a non-testing context, there is also a similar class named ReflectionUtils but this is described as "Only intended for internal use" - see this answer for a good interpretation of what this means.
To address the example in the original post:
Hashtable iWantThis = (Hashtable)ReflectionTestUtils.getField(obj, "stuffIWant");
You need to do the following:
private static Field getField(Class<?> cls, String fieldName) {
for (Class<?> c = cls; c != null; c = c.getSuperclass()) {
try {
final Field field = c.getDeclaredField(fieldName);
field.setAccessible(true);
return field;
} catch (final NoSuchFieldException e) {
// Try parent
} catch (Exception e) {
throw new IllegalArgumentException(
"Cannot access field " + cls.getName() + "." + fieldName, e);
}
}
throw new IllegalArgumentException(
"Cannot find field " + cls.getName() + "." + fieldName);
}
You can use jOOR for that.
class Foo {
private final String value = "ABC";
}
class Bar {
private final Foo foo = new Foo();
public String value() {
return org.joor.Reflect
.on(this.foo)
.field("value")
.get();
}
}
class BarTest {
#Test
void accessPrivateField() {
Assertions.assertEquals(new Bar().value(), "ABC");
}
}
Just an additional note about reflection: I have observed in some special cases, when several classes with the same name exist in different packages, that reflection as used in the top answer may fail to pick the correct class from the object. So if you know what is the package.class of the object, then it's better to access its private field values as follows:
org.deeplearning4j.nn.layers.BaseOutputLayer ll = (org.deeplearning4j.nn.layers.BaseOutputLayer) model.getLayer(0);
Field f = Class.forName("org.deeplearning4j.nn.layers.BaseOutputLayer").getDeclaredField("solver");
f.setAccessible(true);
Solver s = (Solver) f.get(ll);
(This is the example class that was not working for me)
It is quite easy with the tool XrayInterface. Just define the missing getters/setters, e.g.
interface BetterDesigned {
Hashtable getStuffIWant(); //is mapped by convention to stuffIWant
}
and xray your poor designed project:
IWasDesignedPoorly obj = new IWasDesignedPoorly();
BetterDesigned better = ...;
System.out.println(better.getStuffIWant());
Internally this relies on reflection.
Try to go around the problem for the case, the calass of which you want to set/get data is one of your own classes.
Just create a public setter(Field f, Object value) and public Object getter(Field f) for that. You can even do some securoty check on your own inside theses member functions. E.g. for the setter:
class myClassName {
private String aString;
public set(Field field, Object value) {
// (A) do some checkings here for security
// (B) set the value
field.set(this, value);
}
}
Of course, now you have to find out the java.lang.reflect.Field for sString prior to setting of field value.
I do use this technique in a generic ResultSet-to-and-from-model-mapper.