2

I need to code a method, something like :

MyClassObject convert(Class MyClass , String value)

The convert method's job is to convert the String into an object of MyClass, where MyClass can be anything (except a primitive) - Integer, Boolean, Character, Date... the possibilities are huge here - and that's the reason I gave up my stupid if-else block to handle all the cases individually.

I could see something related to this for C# (don't know if it works) , don't know if we have a Java equivalent for this or this

I understand not everything can be converted from a string, I am ready to handle exceptions for non-parseable items.

I don't know if this is possible or not. If not, please help me with a proper design pattern for my code.

Thanks !

Improve this question
10
  • 3
    Does this convert method need to be the reverse of toString, or are you O.K. with serialization? Commented Jan 30, 2012 at 16:21
  • @ruakh : Sorry cant understand how is this possible through the serialization link you offered. Can you plz elaborate ? Thanks ! Commented Jan 30, 2012 at 16:26
  • 1
    Use any form of string-based serialization (XML, YAML, JSON, Avro, Thrift, etc). Commented Jan 30, 2012 at 16:33
  • Serialization offers a way to store an object in a String; but the Strings that it generates are not intended to be printed. They contain garbage characters. The only thing that they're useful for is converting them back into objects later. Commented Jan 30, 2012 at 16:33
  • 1
    @Raj If you're inventing your own generic serialisation library, writing ugly code to deal with special cases kind of comes with the territory. The closest thing I can come up with are PropertyEditors, and the PropertyEditorManager class used to register and look them up. They've got a lot of Swing-related clutter though, and you only get free implementations for the primitive types in the JDK. (Also, their API is a little weird.) Commented Jan 30, 2012 at 23:46

2 Answers 2

Reset to default
3

Your best bet is probably the ServiceLoader mechanism. This allows you to define a pair of interfaces, e.g.:

interface StringConverterProvider{ StringConverter<T> getConverterFor(Class<T> clazz); } interface StringConverter<T>{ T convert(String s); }

... and then locate all the implementations of these interfaces available at runtime, like so:

ServiceLoader<StringConverterProvider> converterProviderLoader = ServiceLoader.load(StringConverterProvider.class); T convert(String s, Class<T> t){ for(StringConverterProvider scProv : converterProviderLoader){ StringConverter<T> converter = scProv.getConverterFor(t); if (converter != null) return converter.convert(s); } return null; }

You make your implementation of the interfaces available to ServiceLoader by listing them in a special file in the META-INF directory in your jar file; see the javadoc for details.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

From what I read, ServiceLoader is an "anti-pattern" and should be avoided. But for now, this seems the only option for me to proceed !
@Raj: I'm curious where you read that, as I've started using it lately and have been pretty satisfied with it.
2

Using reflection and hoping that all the wrapper objects for primitives contains a constructor with a string argument for value, you may be able to achieve this like the following

// A sample test with main public static void main(String[] args) { Object obj = create(Integer.class, "54896"); Integer val = (Integer) obj; System.out.println(val); } // Method to create the desired object with the given value private static Object create(Class myClass, String value) { Object obj = null; try { Constructor constructor = myClass.getConstructor(new Class[]{String.class}); obj=constructor.newInstance(value); } catch (SecurityException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (NoSuchMethodException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IllegalArgumentException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (InstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (IllegalAccessException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (InvocationTargetException e) { // TODO Auto-generated catch block e.printStackTrace(); } return obj; }
Improve this answer

7 Comments

Having such constructor is a pretty impractical assumption for my code.
If that's true...then doing this reflectively, or at all, is a pretty impractical assumption for your code.
@LouisWasserman: If "doing this reflectively" is impractical, can you please propose alternative to achieve this ? I am free to drop reflection if anything else works.
If there is anything that can convert a string to an object of the desired class, it will definitely have a String argument constructor if it is a platform class, or you provide one if it is created by yourself. I completely agree with Louis Wasserman that in other cases it is a pretty impractical assumption for your code.
Call the code directly. Construct the values explicitly. Do it out the long way, writing the code to generate inputs for each method by hand for each method individually. There isn't a better way, is what I'm saying.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.