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)
Related
I was writing some code and was going to throw a RuntimeException as a default for something, when I noticed that there are two options for RuntimeException - one from java.lang and one from kotlin:
Inside the kotlin version of this, there's an entire list of other methods which work the same way :
So, from my understanding of this, the one from package kotlin is simply an alias for the java equivalent (correct me if I'm wrong) which leads me to the question :
what is the point of having this alias file and when should you use it over the "standard" java equivalent ? Does this simply save a few imports ?
When using the JDK, these map to JDK classes. When using Kotlin for Javascript, they would map to a specific implementation in the Kotlin Javascript library. Documentation about actual and expect here.
To answer your question, if there's a chance of you porting your code to also work on another platform, always use the kotlin. variant. Otherwise, it doesn't matter.
In my opinion typealias is strong feature provided by Kotlin language.
Why? Because it gives ability to extend code to multiple domains like extension to provide interoperability between any other languages and Kotlin.
It also becomes helpful when providing APIs or SDK with semantic versioning without worrying much about changes affecting on lower versions of APIs.
One good example would be Collections derived from Java to Kotlin language with some additional & powerful methods as typealias (Literally it saves lot of development time and efforts).
Another good example would be multiplatform programming support by Kotlin language that helps you create APIs with actual and expect keywords implementation.
So long story short, I prefer using RuntimeException from Kotlin package to extend support amongst variety of Kotlin versions (You can see newly added classes starting from version 1.3, but doesn't affect existing API).
GWT uses code generators with a GWT.create() command to generate implementations. This provides a declarative way of doing things in GWT but I don't understand why it's not done with annotation processors like in most java.this articleis what original made me think of it. It seems like it would simplify the build and let you see your compile time errors and be much more compatible with regular java. This is a side question but am I the only one that thinks GWT should support reflection. I've heard that this makes the code slower but still. Isn't it worth it in some cases?
GWT was created before annotations even existed in the Java language/platform (Java 1.4), this is why.
New developments tend to lean towards annotation processing though, and it will eventually be supported as part of a SuperDevMode recompile (you currently have to run your annotation processor and have SDM pick the –modified– generated sources); one example is Dagger 2.
I however don't think this approach is applicable to all cases where a generator is currently used in GWT.
As for GWT.create(), it'll still be needed/useful for the replace with cases of deferred bindings.
As for reflection, it's not about "slowness", it's about the metadata that would need to be embedded into the generated JS code to support runtime reflection. Given that everything is known at compile-time though, there's hardly any need for reflection at runtime; you can generally use compile-time generated code as a replacement for runtime reflection. So no, it's not worth it.
I'm coming up with performance goals for the new year, and I thought I'd be fun to put a goal to reduce the size of the code base, especially boilerplate. One action I've come up with to address this is to use Project Lombok to make beans as short as they should be. But I have a habit of overlooking downsides to new software and approaches, so I'm relying on the Stack Overflow community: Can anyone tell me why Lombok is a bad idea?
A limitation of Lombok is the fact that it is closely tied to the java compiler. Since the annotation processor API only allows creation of new files during the compilation (and not the modification of the existing files) lombok uses that API as a entry point to modify the java compiler. Unfortunately these modifications of the compiler make heavy usage of non-public APIs. Using lombok may be a good idea but you must be aware that upgrading your compiler may break your code. The probability is low but I always feel uncomfortable using non-public APIs.
In my opinion source code in "Java+Lombok" is not Java source code anymore. I see it as something similar Borland company made many years ago in their Borland C++ Builder IDE for VCL - they introduced "properties" in C++ code effectively introducing some kind of a new programming language that wasn't C++ anymore (not C++ in sense of standard of C++ language). Sources using "Java+Lombok" are not valid sources in sense of Java language specification. Moreover I think annotations were not designed to influence language semantic.
A major downside is IDE support. Since Lombok is not actually a language change, and since your IDE only understands java, you will need an IDE that supports Lombok to get things working right. As of now, that's only Eclipse that includes Eclipse and IntelliJ. If you use eclipse that might be ok, but remember that you are making a decision for future developers as well.
I'd suggest you consider moving some of your code into a less ceremonial language such as groovy. We've had success moving some of our business logic and models into groovy and it works really smoothly.
One potential disadvantage to something like Lombok is that with the setters/getters "missing", source tools may not "recognize" aspects of the resulting object that give it "bean" qualities, since those qualities only manifest in the compiled class.
Another disadvantage is that it's Yet Another piece of "black magic" within the tool chain. Fortunately, it seems to be a rather benign piece (I have not used it), and the fact that it happens at compile time rather than runtime is actually a blessing (IMHO). But, you're not going to be able to reuse or share your code without the project since it's adding artifacts to your code base. So, while the compiled class file may be a "POJO", I'd argue that your source code is NOT a POJO.
Neither of these are crippling downsides, rather just aspects to be aware of looking forward.
As pointed out by user #Jcs in another answer, i would like to add more.
In our project we, are using mapstruct which is used to generate mapper classes, before the code is compiled, using mvn generate-sources command, this is done at process phase using maven processor plugin.
project lombok adds the bytecode for the getter/setter in class file at compile phase.
since process phase is executed before the compile, it finds that there is no getter/setter available in class.
There are some workarounds available to execute compile phase more than one.
See this git hub ticket for more details.
Note : I am using STS ide by Spring and it is supported by lombok :)
It's a third party library, and there are developers who don't know it well.
IDE should support annotations processing (there are plugins for IDEA and Eclipse).
As was mentioned above, your code will be without getters/setters. It leads to sonar/checkstyle violations.
In my opinion, The most obvious risk with Project Lombok is that when you decide to use lombok, you also decide that everyone else who deals with your code uses lombok. This is a true statement for all libraries, but Lombok is special in that it is a build-time dependency and your IDE needs plugins to figure out what is going on. That means anyone who has reason to touch your code ex. someone trying to debug weird behavior, etc.) needs to know how to set it up and how it works. That can be a little frustrating.
To add to other responses.
The main reason to not use it is a new record keyword added as experimental feature in Java 14. Java 16 brings records out of preview which will make project Lombok obsolete in most cases.
Since Java 14 one is able able to write:
record Book(String title, String author, String isbn);
which gives automatically access to the constructor, getters/setter, hashCode, equals and toString methods without any annotations.
I like generics a lot and use them whereever I can. Every now and then I need to use one of my classes in another project which has to run on an old JVM (before 5.0), needs to run on JavaME (where generics are not allowed neither) or in Microsoft J# (which has VERY poor Support for generics).
At the moment, I remove all generics manually, which means inserting many casts as well.
Since generics are said to be compile-time-only, and every piece of generic code could possibly converted to non-generic code automatically, I wonder if there is any tool which can do this for me.
If there is no such tool, how else could I solve the problem? Should I completely stop using generics?
There already are answers related to bytecode compability. What if I need source code compability for some reason?
You need to use something like Retroweaver in order to achieve this sort of thing. The other answers on this question are slightly misleading. Generics are sort-of bytecode compatible with previous versions, but not entirely (see java.lang.reflect.Type if you don't believe me). Also, there is an issue of the bytecode version attribute, which will prevent a class compiled against 1.5 from running on a previous version. Retroweaver works around both problems while also enabling other Java 5 features like annotations and enums.
In Netbeans (I'm not sure about what IDE you are using) you can set the source-code compatibility to a set java version - just set it to one that supports generics. As already posted, generics are bytecode compatable with old JVM / JRE versions and so it should hopefully work out of the box.
To the best of my knowledge Java 5 is not byte-code compatible with Java 1.4. That is, You cannot use Java 5 compiled classes with an earlier VM.
You can check retroweaver. This was mentioned a lot when generics were introduced. I personally have no experience with it.
Did you ask Google? My search turned up http://www.publicobject.com/glazedlists/documentation/Generics_and_Java_1.4_with_one_codebase.pdf, which seems a very interesting approach.
Its bytecode compatible, it should work out of the box with an old interpreter.
I am a fan of static metaprogramming in C++. I know Java now has generics. Does this mean that static metaprogramming (i.e., compile-time program execution) is possible in Java? If so, can anyone recommend any good resources where one can learn more about it?
No, this is not possible. Generics are not as powerful as templates. For instance, a template argument can be a user-defined type, a primitive type, or a value; but a generic template argument can only be Object or a subtype thereof.
Edit: This is an old answer; since 2011 we have Java 7, which has Annotations that can be used for such trickery.
The short answer
This question is nearly more than 10 years old, but I am still missing one answer to this. And this is: yes, but not because of generics and note quite the same as C++.
As of Java 6, we have the pluggable annotation processing api. Static metaprogramming is (as you already stated in your question)
compile-time program execution
If you know about metaprogramming, then you also know that this is not really true, but for the sake of simplicity, we will use this. Please look here if you want to learn more about metaprogramming in general.
The pluggable annotation processing api is called by the compiler, right after the .java files are read but before the compiler writes the byte-code to the .class files. (I had one source for this, but i cannot find it anymore.. maybe someone can help me out here?).
It allows you, to do logic at compile time with pure java-code. However, the world you are coding in is quite different. Not specifically bad or anything, just different. The classes you are analyzing do not yet exist and you are working on meta data of the classes. But the compiler is run in a JVM, which means you can also create classes and program normally. But furthermore, you can analyze generics, because our annotation processor is called before type erasure.
The main gist about static metaprogramming in java is, that you provide meta-data (in form of annotations) and the processor will be able to find all annotated classes to process them. On (more easy) example can be found on Baeldung, where an easy example is formed. In my opinion, this is quite a good source for getting started. If you understand this, try to google yourself. There are multiple good sources out there, to much to list here. Also take a look at Google AutoService, which utilizes an annotation processor, to take away your hassle of creating and maintaining the service files. If you want to create classes, i recommend looking at JavaPoet.
Sadly though, this API does not allow us, to manipulate source code. But if you really want to, you should take a look at Project Lombok. They do it, but it is not supported.
Why is this important (Further reading for the interested ones among you)
TL;DR: It is quite baffling to me, why we don't use static metaprogramming as much as dynamic, because it has many many advantages.
Most developers see "Dynamic and Static" and immediately jump to the conclusion that dynamic is better. Nothing wrong with that, static has a lot of negative connotations for developers. But in this case (and specifically for java) this is the exact other way around.
Dynamic metaprogramming requires reflections, which has some major drawbacks. There are quite a lot of them. In short: Performance, Security, and Design.
Static metaprogramming (i.e. Annotation Processing) allows us to intersect the compiler, which already does most of the things we try to accomplish with reflections. We can also create classes in this process, which are again passed to the annotation processors. You then can (for example) generate classes, which do what normally had to be done using reflections. Further more, we can implement a "fail fast" system, because we can inform the compiler about errors, warnings and such.
To conclude and compare as much as possible: let us imagine Spring. Spring tries to find all Component annotated classes at runtime (which we could simplify by using service files at compile time), then generates certain proxy classes (which we already could have done at compile time) and resolves bean dependencies (which, again, we already could have done at compile time). Jake Whartons talk about Dagger2, in which he explains why they switched to static metaprogramming. I still don't understand why the big players like Spring don't use it.
This post is to short to fully explain those differences and why static would be more powerful. If you want, i am currently working on a presentation for this. If you are interested and speak German (sorry about that), you can have a look at my website. There you find a presentation, which tries to explain the differences in 45 minutes. Only the slides though.
Take a look at Clojure. It's a LISP with Macros (meta-programming) that runs on the JVM and is very interoperable with Java.
What do you exactly mean by "static metaprogramming"? Yes, C++ template metaprogramming is impossible in Java, but it offers other methods, much more powerful than those from C++:
reflection
aspect-oriented programming (#AspectJ)
bytecode manipulation (Javassist, ObjectWeb ASM, Java agents)
code generation (Annotation Processing Tool, template engines like Velocity)
Abstract Syntax Tree manipulations (APIs provided by popular IDEs)
possibility to run Java compiler and use compiled code even at runtime
There's no best method: each of those methods has its strengths and weaknesses.
Due to flexibility of JVM, all of those methods in Java can be used both at compilation time and runtime.
No. Even more, generic types are erased to their upper bound by the compiler, so you cannot create a new instance of a generic type T at runtime.
The best way to do metaprogamming in Java is to circumvent the type erasure and hand in the Class<T> object of your type T. Still, this is only a hack.
If you need powerful compile-time logic for Java, one way to do that is with some kind of code generation. Since, as other posters have pointed out, the Java language doesn't provide any features suitable for doing compile-time logic, this may be your best option (iff you really do have a need for compile-time logic). Once you have exhausted the other possibilities and you are sure you want to do code-generation, you might be interested in my open source project Rjava, available at:
http://www.github.com/blak3mill3r
It is a Java code generation library written in Ruby, which I wrote in order to generate Google Web Toolkit interfaces for Ruby on Rails applications automatically. It has proved quite handy for that.
As a warning, it can be very difficult to debug Rjava code, Rjava doesn't do much checking, it just assumes you know what you're doing. That's pretty much the state of static metaprogramming anyway. I'd say it's significantly easier to debug than anything non-trivial done with C++ TMP, and it is possible to use it for the same kinds of things.
Anyway, if you were considering writing a program which outputs Java source code, stop right now and check out Rjava. It might not do what you want yet, but it's MIT licensed, so feel free to improve it, deep fry it, or sell it to your grandma. I'd be glad to have other devs who are experienced with generic programming to comment on the design.
Lombok offers a weak form of compile time metaprogramming. However, the technique they use is completely general.
See Java code transform at compile time for a related discussion
You can use a metaprogramming library for Java such as Spoon: https://github.com/INRIA/spoon/
No, generics in Java is purely a way to avoid casting of Object.
In a very reduced sense, maybe?
http://michid.wordpress.com/2008/08/13/type-safe-builder-pattern-in-java/