Category Archives: Java/Java EE

What’s next for Sun certifications now that Oracle is in charge?

Posted on by
6

At the moment, Sun’s certification page has a preview of the upcoming JEE 6 curriculum.  I’ve saved the image here in case it disappears like the SCJP Plus information did.  The learning paths on Oracle’s site do gel with this info so I think it can be safely assumed this is the plan as of now.

Disclaimer: I have no affiliation with Oracle or Sun.  This entire post is clues/speculation based on what is on the internet.

What is the implied mapping?

Based on the information available, the following chart shows what it looks like Oracle is planning.  Below the chart, I write my evidence for each. This just addresses exam naming at the moment.  I’m sure the content will change over time.  Sun was looking toward changes anyway with the Programmer Plus exam for Java 1.7.  For those uncertain about whether to get certified now, the name is important as is the fact that the certifications have a future.

Current Certification name Future Certification name
Sun Certified Java Associate (SCJA) Same
Sun Certified Java Programmer (SCJP) Same (no word on the programmer plus yet)
Sun Certified Java Developer (SCJD) Not enough info to tell
Sun Certified Web Component Developer (SCWCD) Split into Sun Certified Servlet/JSP developer and Sun Certified JSF developer.  Add JPA to form the Master Sun Certified Enterprise Web Developer
Sun Certified Business Component Developer (SCBCD) Split into Sun Certified EJB developer and Sun Certified JPA developer.  Combine to form the Master Sun Certified Business Application Developer
Sun Certified Developer for Java Web Services (SCDJWS) Renamed to Sun Certified Web Services Developer.  Add JPA and Servlet/JSP to form the Master Sun Certified Web Services Developer
Sun Certified Mobile Application Developer (SCMAD) Not enough info to tell
Sun Certified Enterprise Architect (SCEA) Same
  1. SCJA – As Oracle uses the words associate, professional, master and expert for their own database certification, it is unlikely they would get rid of Sun’s associate exam.  While the SCJA doesn’t show up on the JEE 6 learning path, it didn’t for the JEE 5 one either.  It was treated as an optional pre-requisite to the SCJP or a standalone exam.  I see no reason t his exam would not continue for the forseeable future.
  2. SCJP – Explicitly mentioned in the JEE 6 curriculum.
  3. SCJD – Not part of JEE so no info available.
  4. SCWCD  – The JEE 6 learning path shows this split into Servlet/JSP and JSF.
  5. SCBCD  – The JEE 6 learning path shows this split into EJB and JPA.
  6. SCDJWS – The JEE 6 learning path clearly shows this as a renamed exam.
  7. SCMAD – Not part of JEE so no info available.
  8. SCEA – Explicitly mentioned in the JEE 6 curriculum.  Continues to be independent of the other exams.  (The SCJP pre-requisite has only been for training classes, not for the actual exam.)

What is implied overall?

  1. There are more exams in the new world.  More money for Oracle.
  2. Exams combine to form “master” certifications in an area.  This is good if you want to get certified on just part of an area.  Say you don’t use JSF or EJB but want the other part of the certification.
  3. The word “Sun” is still in the name.  This is good for Oracle as far as branding goes.  Keeping Sun as a brand preserves the legacy built around the certifications.  There is some precedence for this.  The Hyperion and Peoplesoft certifications still have their old parent’s names.

Interesting facts:

  1. This image is named Java-EE-6-Curriculum-Path_option2.gif.  Option 1 is not available on the web server, but is shows some thought has gone into the new certifications.  While these are class listings rather than certification details, but still give some insight into the thinking going forward.
  2. Oracle’s learning paths show the difference between JEE 5 and JEE 6. (When clicking the links, you may have to choose a country and then go back to click the link again.)  The fact that they mesh with the roadmap on Sun’s site shows good consistency.
  3. Oracle’s learning path for core Java is the same.  It still shows the programmer, developer and mobile paths.  It hasn’t been updated in a while so we can’t assume much from this.
  4. We know Oracle is planning JEE 6 exams under the Sun branding.  They are currently advertising betas for the Sun Certified EJB Developer and the Sun Certified JSP and Servlette Developer.  And no, that’s not a typo.  Oracle seems to think “Servlet” is spelled “Servlette.”

What’s next?

Only time will tell.  Until Oracle announces things, all we can do is look for clues.

what may or may not be in java 7 from the java road trip

Posted on by
7

Oracle talked about Java 7 at the first stop of the Java Road Trip. The main speaker was Brian Goetz, author of Java Concurrency In Practice.

Despite the disclaimer that everything including syntax is subject to change, the talk was pretty interesting.  Here are my notes.  (this was largely written on my iPad; please excuse any typos)

Modularity

  • The JRE download is 13mb, but most code doesn’t get run by ordinary apps
  • The monolithic jdk makes new releases of platform take longer to roll out
  • Modularizing apps helps with jar hell and finding out at runtime that something is missing/wrong
  • Will provide mechanism for apps to express dependencies in way useful to both humans and tools
  • Based on concepts in Maven and OSGI
  • Current draft has: Module-info.java defining module and version number along with what module and versions or ranges you depend on
  • Classpath will be legacy mode, preferred mode will be to turn your app into a module

Multi lingual support

  • JVM is a managed code environment
  • Scala is a lot like java, but other dynamic languages (like Ruby) run slower because need to rely on reflection or code generation.
  • JVM is more like Smalltalk than like Java , but some places is tied to Java
  • Da Vinci machine project is targeted to adding features to better support dynamic languages. In particular dynamic method linkage which is being able to select version of method based on type of arguments
  • Invokedynamic vs invokevirtual for method selection and linking. Once calls stabilize, don’t look up in vm anymore, then inlines and is as fast as in  java.  This is a goal, need to get there.

Productivity

  • Project coin – add half a dozen small language changes to simplify everyday tasks.  Would be at  level of enhanced for loop
  1. Reduce boilerplate of generics with the the diamond operator (not really an operator) 
    Map<String, String> map  = new HashMap<>();
  2. Better numerical literals to make long numbers more readable.  Similarly for binary (long string of 0’s and 1’s) 
    long cc= 123_5678_567;
  3. Collection literals – declare inline like we do with arrays and hard coded data.  More declarative. Like associative array in Perl, but may not go that far
  4. Automatically close resources in try/catch.  Better idiom 
    try (InputStream in = createInputStream()){
// code that reads in from stream goes here
} // compiler will call close for you here

Performance

  • Goal: facilitate scalability across multiple cores
  • Fork join extend recursive action to split into subtasks and join to get answer.
  • Will be added to concurrency utilities.
  • Don’t have to tell it how many cores you have
  • ParallelIntArray class automates common operations filter, map and reduce so can say what want to do declaratively

Closures

  • Saving the best for last.
  • Like anonymous inner classes but without boilerplate of anonymous inner classes
  • Still debating syntax
  • Still debating whether return type should be declared
  • Still discussing how to extend interfaces (will be used to add closures for Collections).  Options are “static extension methods” like in C# where you statically “pretend there were these methods are on the class and call the static methods instead.”  Also discussing ” virtual extension methods.”  Either way the closures project will finally address the issue of api evolution
#(int x)(x*3).domorestuff()

dbunit vs recreate schema

Posted on by
Reply

As I continue looking at writing integration tests for the back end of JavaRanch’s JForum install, I faced the decision of how to guarantee a clean database.  A previous post on the topic covers how to clone a postgresql database via the command line.

I was originally thinking about using dbUnit to import data.  I may still do that if I find myself needing a lot of data.  However, I realized it was more important to be able to recreate the table structure each time.  Our database schema changes regularly as we enhance tables and I don’t want people to have to update the exported dataset. The concept is to have the test create the schema/tables/data from scratch each time it runs.

Some interesting things in this infrastructure:

  1. JUnit suite wide setup – I had so much to say on this topic that I wrote a separate blog post on it.
  2. Main method – The main method is interesting because it provides the starting point. It sets up the database (more on that later) and kicks off all the JUnit tests. It uses the JUnit runner to benefit from JUnit’s reporting mechanism. I also added logging for the database setup in case it took a long time on someone’s machine. This turned out not to be a problem. At the moment, I’m leaving it “just in case.” 
    public static void main(String[] args) throws Exception {
long start = System.currentTimeMillis();
setUp(args);
long end = System.currentTimeMillis();
System.out.println();
System.out.println("Done setting up database in " + (end - start) + "ms.  Now running tests.");
System.out.println();
JUnitCore.main("com.javaranch.test.functional.All_JForum_Functional_Tests");
}
  3. Pointing to a test database– Many developers, including myself, have test data in their “jforum” database and wouldn’t appreciate the integration tests mucking around with it. As a result, the integration tests use a special “jforum_integration_test” database. This database has its schema recreated each run of the test. Conveniently, JForum has a property for the database name that all the code uses. Having the code update this in setup is sufficient. 
    SystemGlobals.setValue(ConfigKeys.DATABASE_CONNECTION_DBNAME, "jforum_integration_test");
  4. Tear down first
    A common pattern when integration testing is to call tear down before setup. Tear down drops the “public” schema. (which is where postgresql stores everything) Setup creates the schema and loads the DDL/SQL. This is done in a DatabaseController class to keep the All_XXX_Tests class uncluttered. For example:

    conn.prepareStatement("DROP SCHEMA public CASCADE;");
  5. Running a DDL file – This is a blog entry in and of itself. Which is good because I made it on

Conclusion
I’ve been using this test structure for a couple weeks now. It has served the purpose well and I expect it to live on. A nice side effect is that we find out very quickly if the DDL is incorrect in SVN!