Before re-inventing the wheel, I thought I'd see if anyone is aware of an updated version of something like apache commons-beanutils (basically interested in using reflection-based services for populating and extracting bean values), especially one that supports generics.
I don't believe that there is any current library which allows reflection of Java generics. When Java generics were introduced in Java 1.5, they were implemented in the compiler but were not implemented in the VM. So you have a problem of type-erasure when trying to reflect upon a class which implements generics as the types are only visible at compile time and not at runtime. To see more about this and possible work-arounds, check out:
Super type tokens
Reflecting generics
Scala's way of working around reified types
Related
Say I have a scala library that exposes api methods that take scala specific types (say a collection that isn't available in java).
Does this mean you have to either change the exposed parameter, or change the collection to a java compatible type and then iterate over it and initialize the scala specific collection?
Basically what I am getting at is, when designing a scala api that will be used in java, you have to use a compatible type or you pay performance/memory penalty if you have to iterate and map the java collection to the scala one right?
Is that basically what the options are?
From http://www.scala-lang.org/faq/4
What does it mean that Scala is compatible with Java?
The standard Scala backend is a Java VM. Scala classes are Java classes, and vice
versa. You can call the methods of either language from methods in the
other one. You can extend Java classes in Scala, and vice versa. The
main limitation is that some Scala features do not have equivalents in
Java, for example traits.
Also, to answer your question, plase visit How to use scala.collection.immutable.List in a Java code
I have to work was a little bit outdated JVM which supports only Java 1.4. I would like to use generics in my code, which is possible according to this article http://www.ibm.com/developerworks/java/library/j-jtp02277/index.html. Unfortunately, Collections classes in our library are not generic and they cannot be replaced (which means I cannot use http://download.oracle.com/otndocs/jcp/jsr14-2.4-ea-demo-oth-JPR/). An obvious solution is to write generic wrappers for all main classes - ArrayList, HashMap, HashSet and create generic interfaces Map, etc. This is quite a work to do, so I am wondering if there might be already a library which provides this functionality.
Can you compile your code for a JVM 1.4?
If your code is compiled for Java5 (6 or 7) you'll probably get a "bad version in class file" -Error.
If you use any compiled library, all have to be compiled for Java 1.4.
Is there any tool that might help in converting the Java code written using 1.5 to 1.4. This is required because i need to reverse engineer my project using STAR UML. and Star UML is Java 1.4 compatible.
Please Help
Maybe you can try with retroweaver, it works on byte code level though, and I don't know if it's enough for your tool.
To review the changes between Java 1.4 to Java 1.5, the most important is probably generics, then auto boxing and auto unboxing, annotations, variable number of arguments, the foreach loop, and import static.
Generics: At a source code level, while you could probably get rid of generics when used as the collection element type, more difficult will be when a generic type is returned by a method.
Auto boxing/unboxing: will need explicit conversions.
Annotations: since they enable declarative programming, if used they might be difficult to substitute. With Spring, for instance you can define the same behaviour with XML, but it would be hard to convert by hand and also a bad idea.
Variable number of aguments: will have to use arrays.
Foreach loop: have to use iterators explicitely.
import static: just prepend the class name.
It was a pretty good advancement of features from Java 1.4 to 1.5, I wrote this more as a review of the changes, but unless your code is using very little of the new features you'll end losing a lot of time and also you'll reduce the quality of your code, so as sethu advised you probably the easier path is find another tool.
You can do it with NetBeans by selecting the Java platform you want in the properties folder.
Then is going to mark as wrong all the code non compatible with Java 1.4.
(But maybe you should follow the #sethu advice)
After reading some OpenJDK mailinglist entries, it seems that the Oracle developers are currently further removing things from the closure proposal, because earlier design mistakes in the Java language complicate the introduction of the Java closures.
Considering that Scala closures are much more powerful than the closures planned for Java 8, I wonder if it will be possible to e. g. call a Java method taking a closure from Scala, defining a closure in Java and giving it to a Scala function etc.?
So will Java closures be represented like their Scala counterparts in bytecode or differently?
Will it be possible to close the gap of functionality between Java/Scala closures?
I think it's more complicated than assuming there's two groups of stakeholders here. The Project Lambda people seem to be working mostly independently of the Oracle people, occasionally throwing something over the wall that the Project Lambda people find out indirectly. (Scala, is of course the third stakeholder.)
Since the latest Project Lambda proposal is to eliminate function types all together, and just create some sort of fancy inference for implementing interfaces that have a single astract method (SAM types), I foresee the following:
Calling Scala code that requires a Scala closure will depend entirely on the implementation of the Function* traits (and the implementation of traits in general) -- whether it appears to the Java compiler as a SAM (which it is in Scala-land) or whether the non-abstract methods also appear abstract to the JVM. (I would think they currently do look like they're abstract since traits are implemented as interfaces, but I'm know almost nothing about Scala's implementation. This could be a big hurdle to interperability.)
Complications with Java generics (in particular how to expressInt/int/Integer, or Unit/Nothing/void in a generic interface) may also complicate things.
Using Scala functions to implement Java SAMs will not be any different than it now -- you need to create an implicit conversion for the specific interface you wish to implement.
If the JVM gets function types (and Oracle seems not to have eliminated that possibility), it may depend how it's implemented. If they're first class objects implementing a particular interface, then all that Scala needs to do to be compatible is make Function* implement the new interface. If a new kind of type is implemented in the JVM entirely, then this could be difficult -- the Scala developers may wrap them using magic like they currently do for Arrays, or they may create create implicit conversions. (A new language concept seems a bit far-fetched.)
I hope that one of the results of all of this discussion is that all of the various JVM languages will agree on some standard way to represent closures -- so that Scala, Groovy, JRuby, etc... can all pass closures back and forth with a minimum of hassle.
What's more interesting to me is the proposals for virtual extension methods that will allow the Java Collections API to use lambdas. Depending on how these are implemented, they may greatly simplify some of the binary compatibility problems that we've had to deal with when changing Scala code, and they may help to more easily and efficiently implement traits.
I hope that some of the Scala developers are getting involved and offering their input, but I haven't actually seen any discussion of Scala on the Project Lambda lists, nor any participants who jump out to me as being Scala developers.
You would likely be able to do this extremely easily using implicit conversions a la collection.JavaConversions whether or not they come out of the box.
Of course, this is not obviously so, because it may be the case that Java closures are turned into types which get generated by the JVM at runtime - I seem to recall a Neal Gafter presentation saying something along these lines
Note: 5 years later, SCALA 2.12.0-M3 (Oct. 2015) did include this enhancement:
Scala 2.12 emits closures in the same style as Java 8.
For each lambda the compiler generates a method containing the lambda body.
At runtime, this method is passed as an argument to the LambdaMetaFactory provided by the JDK, which creates a closure object.
Compared to Scala 2.11, the new scheme has the advantage that the compiler does not generate an anonymous class for each lambda anymore. This leads to significantly smaller JAR files.
I'm becoming increasingly frustrated with the limits of type-erased Java generics. I was wondering if there was a custom Java Compiler that provided a full version of generics without the quirks associated with type-erasure?
Chris
It is not just a compiler change that would be required. I think it would also be necessary to change the JVM implementation in ways that are incompatible with the JVM spec, and the Java class libraries in ways that are incompatible with the current APIs.
For example, the semantics of the checkcast instruction change significantly, as must the objects returned by the Object.getClass() operation.
In short, the end result would not be "Java" any more and would be of little interest to the vast majority of Java developers. And any code developed using the new tools/JVM/libraries would be tainted.
Now if Sun/Oracle were proposing / making this change ... that would be interesting.
Scala (a language which runs on top of the JVM) may allow you to get around the problem of type erasure using the powerful concept of manifests, which essentially give you reified types.
More info: http://www.scala-blogs.org/2008/10/manifests-reified-types.html
Question is meaningless unless you are asserting that the JDK compiler doesn't implement the language correctly. Any compiler that didn't obey the same rules wouldn't be a Java compiler so nobody could recommend its use.
It would be doable, but I'm not aware of anyone that's done it yet. It would require a significant rewrite of javac to make it instantiate generics when needed (creating a new .class file for each instantiation), but otherwise should be reasonably straight-forward. It could even add support for using primitive types as generic type args.