Out of curiosity, I wrote an own simple implementation of Set for a special case (where the set of all possible entries is fixed, but it's no enum). It was actually quite easy, but obviously, my implementation is unusable without a lot of tests (and maybe even then, but that's another topic; it was mainly an exercise).
So is there any testsuite available I could use for unit-testing it?
Use the Guava SetTestSuiteBuilder.
https://github.com/google/guava/blob/master/guava-testlib/src/com/google/common/collect/testing/SetTestSuiteBuilder.java
Examples:
https://github.com/google/guava/blob/master/guava-testlib/src/com/google/common/collect/testing/TestsForSetsInJavaUtil.java
It is released as part of "guava-testlib" in maven central.
Oracle refuses to open source the test suite for java, this is the heart of a debate between the OSS community and Oracle.
See here for more info:
http://arstechnica.com/open-source/news/2010/12/apache-resigns-from-jcp-in-protest-of-oracle-governance-failures.ars
So I doubt there is anything you can do to verify you conform to the standard.
Here's an excerpt:
The heart of the issue is that Apache can't certify that its open source Java implementation—called Harmony—conforms with the Java language standards because Oracle refuses to supply the necessary test suites under a suitably open license. Oracle's position on the issue falls afoul of JCP policies, which stipulate that standards and other relevant materials must be freely redistributable and made available under terms that are conducive to enabling third-party open source implementations.
This conflict has been a subject of considerable friction for quite some time, because Sun similarly denied the ASF appropriate access to the test suite prior to Oracle's acquisition of the company. Oracle had initially sided with Apache in calling for the test suites to be published under open terms, but reversed its position after acquiring Sun. Oracle's approach to this issue suggested very strongly that the company would likely not be willing to fix any of the long-standing JCP governance problems that had arisen under Sun.
Related
JEP 11: Incubator Modules:
Summary
Incubator modules are a means of putting non-final APIs and non-final tools in the hands of developers, while the APIs/tools progress towards either finalization or removal in a future release.
Goals
Enable JDK Release Projects to distribute a limited set of APIs and tools that ("are" is probably missing on the website) not final and complete, and which would benefit from developer or user feedback. This will reduce the chance of costly mistakes in the Java SE Platform and the JDK.
JEP 12: Preview Features:
Summary
A preview feature is a new feature of the Java language, Java Virtual Machine, or Java SE API that is fully specified, fully implemented, and yet impermanent. It is available in a JDK feature release to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future Java SE Platform.
Goals
Allow Java platform developers to communicate whether a new feature is "coming to Java" in approximately its current form within the next 12 months.
I am wondering what is the point of having these two, conceptually (even semantically), quite similar aspects, separately?
Yes, JEP 12 has more Goals, slightly different definition and summary; and it seems to have closer connection with JVM internals; however, still, these two JEPs seem quite overlapping to me.
Any ideas?
Answer from Stuart Marks:
Incubation applies to modules, and a preview feature is something that is more closely tight in with the language and the libraries.
Followed up by Brian Goetz:
Preview features are really finished but are waiting for a round of feedback
whereas the incubator mechanism has more room to iterate over the api several times to get feedback.
Source:
Video from Devoxx where the Java architects answer this question:
I came across the sum.misc.Unsafe class when reading the implementation of ForkJoinPool. But no source code or api docs were found in the JDK.
Where can I find the source code or api docs for the sun.misc.*
For Java source code, I usually go to GrepCode
While such code is available (see Binyamin's post) it is generally a very bad idea to write anything that needs such code.
First, you are not generally assured that any JVM has such a class available (only JVMs descending from SUN's codebase would contain non-published, non-standard, SUN specific libraries). Also, since these are not standard libraries, you can't really depend on them being present or unchanged in subsequent releases of the SUN JVM.
I am looking for nice (java) code generation engine.
I have found cglib but it is very poorly documented and I am not quite sure that it can generate actual java classes (files) and only dynamic classes. If I am wrong maybe someone knows has a link with an example.
Roman
Have a look at codemodel, used with success for my projects.
Didn't really try, but you may want to take a look at another code generation Java framework called Javassist, which also has pretty thorough tutorial. Also Hibernate changed code generation framework from cglib to javassist. Quote, explaining why:
The simple fact of the matter is that development on CGLIB has largely stopped. It happens. Developers for whatever reason (the reasons are their own) move on to new priorities.
Source
I just released cgV19 here: https://github.com/carstenSpraener/cgV19 it's based on a code generator i wrote in 2002 to 2006 and which is still in production use. cgV19 is a re implementation with lessons learned. It has:
Support for gradle
Uses Groovy as a template language
a modular "cartridge" system to add several generator for different aspects
small footprint
Just try it out and give me feedback would be very nice.
We are currently using MICO to establish the communication between a server and a client, where the client is a simulator written in C++ and the server is a java program displaying an animation of what happens in the simulation. It seems that the developemt of MICO has slowed down to an almost halt and bugs that only allow us to hack around them (as we don't have the time to first figure out which parts of MICO are responsible for codegeneration and so on) keep us from making real progress.
So, does any one of you know of a good drop-in replacement? We would like to have the following:
The compiler can generate both C++ and Java-Code from the idl.
The project should still show considerable support.
The implementation should be open-sourced (GPL or BSD, or something alike), as we use our programs to teach students as well.
The migration from MICO should be as easy as possible. (This is not a hard requirement, but would be a good thing)
I found some other CORBA implementations, e.g. TAO, but I didn't find any of which I could
say that they are still supported. Correct me if I am wrong here.
The Free CORBA® Downloads page might be of interest to you.
Just naming:
orbit2 1, also pyorbit etc.
omniORB
TAO (has already been mentioned)
1 On my Ubuntu box, apt-rdepends -r liborbit2 returns 5530 lines...
I don't know where CORBA or MICO in particular has gone in the last 5 years, but back then a drop in replacement was not really possible, since differences between vendors where still there.
Not necessarily API differences (POA, etc.) but
in implementation behavior,
in custom extensions which were required to make it work in a real-world environment (threading, load balancing, security, etc.),
in how the development tools worked
and also about the whole deployment or runtime story.
We had Orbix ASP/2000/Whatever and ORBacus which were interchangeable having a small compatibility layer, some Makefile framework to hide differences in tools (e.g. the IDL compiler) and some scripts for wrapping ORB specific processes.
Unfortunately, ORBacus has long been bought by (then) IONA, which already make Orbix. IONA itself has been bought by someone else (I forgot). The original authors of ORBacus, plus some devs from IONA Orbix, changed their ways somewhat and produced Ice, which is not CORBA but somewhat alike - of course without the glitches ;-)
Concerning TOA, I think it would be the "best" choice concerning still being developed as it is driven by research on the Washington University. But last time I looked, they didn't have Java implementation but people seemed to use JacORB.
Maybe all this helps you little, unless it brings even more confusion :-)
TAO as C++ ORB is still actively supported and developed (see http://www.cs.wustl.edu/~schmidt/commercial-support.html). For Java I would propose JacORB.
On http://www.orbzone.org there is an overview of available corba implementations.
I'm required to write a JCE provider. I have learned that I need to use the bouncy castle clean room implementation. Could you please tell me what "clean room implementation" means in in this context?
Clean room implementation means in this context that the code was written only from the description and specification, but not with access to any potentially troublesome code.
This is important as the Sun source code previously was under a license which was incompatible with especially GPL distributions. By ensuring that the code was not written without any access to such code, it is guaranteed that the Sun license could not later be found to apply to the clean room implementation, and then again be incompatible with the GPL license or any other restrictions.
In other words, it is a guarantee that the license shown will hold.
Despite the name, most re-implementations are done in rooms with mostly empty beer cans and pizza boxes. This is speaking from past experience, you understand :-)
However, in the context of chip development, a clean room is one where small imperfections (like dust) can cause serious problems at the nano scale. So they're kept incredibly clean, with air scrubbers, protective suits (protecting the environment, notvthe wearer) etc.
By analogy, software clean room development is done without any access to imperfections that could cause problems. In the case of open-source software, this means not having access to an implementation that might be "tainted" by an incompatible license. (It's not just GPL, but this is commonly cited due to its viral nature). However, this also applies to closed source reverse engineering projects, like the creation of the IBM compatible BIOS that opened the market to IBM clones back in the 80's.