RSS

Tag Archives: jdk

Java: everything should be public

If not everything then at least all of the methods and classes.

I wish I new the history of this decision and more importantly what is keeping this artifact of the language in place. I suppose from a historical perspective it has not really caused any trouble. The language designers had some ideas that were rooted in commercial software and commercial software libraries. I’m remembering various commercial JDBC drivers, crypto drivers, X.25 drivers, MQ drivers. But in the modern development environment black box development is no longer the norm; so it might be time to change with the times.

Looking at Ruby, Perl, Python, even Groovy. They are all dynamic languages. They are all compiled or processed at runtime and so there is no benefit to private or protected objects. The code is there for the reading if you are so inclined. Java and C++ are compiled languages. Java does have some capability for runtime meta programming. But while historically developers purchased libraries to supplement the core JDK, they are now using Maven repositories like Ruby’s Gems, Python’s PyPi, and Perl’s CPAN.

private and protected are now more for vanity than any “protection” that the Java’s creators had envisioned.

 
Leave a comment

Posted by on 2012/05/09 in ProgLang

 

Tags: , , , , , , , , ,

IntelliJ+Grails is not that bad sort of…

Essentially, JDK 7 is OpenJDK, and there still are known issues with running IDEA under OpenJDK. Oracle JDK 6 works best in our experience

I have been writing java code since it’s first release. At the time it did not do much so I did not actually deploy anything. Around the time of version 1.0.2 it was stable and robust enough to build production applications that would run under both Sun and Microsoft operating systems.

Happily I moved away from the JDK and toward perl, python, ruby and erlang only to be dragged back into the fold. Java has changed a lot over the years. (a) there are a lot more APIs, (b) tools and IDEs are everywhere. Game changers include many of the Apache projects and a good number of 3rd party libraries.

Now I’m getting back into the swing of things. IntelliJ, from JetBrains, is as I remember. JB is undoubtedly pushing the capabilities of the environment, the language and the different SDKs. But on many levels it feels unnatural.

Take the quote at the top of the article. I do not know the guy who wrote the quote or his affiliation but I do know that versioning and deep dependencies drive me nuts. Also the notion of private and protected functions and classes is a joke and flies in the face of full stack awareness.

The thing that get’s me where I live is that first part of the JDK expectation is that it runs everywhere. The second thing is that JDK versions are not supposed to matter; when clearly they do. Or at least they matter a lot more than I want them to.

 

Tags: , , , ,

Scala + Clojure

I just wrote an email to a friend that started out as a note and turned into a speech.

I spent some time on both. There is nothing unusual about either of them. (a) they still depend on the JVM (b) for whatever functional goodness they profess to have they depend on the JVM and more importantly they are still inheriting from libraries that use the standard JDK. So unless they and your app use PURE scala or clojure libraries (see that Lift uses Jetty) it’s just a non-event for now.
PS: for all the benefits of “private” and “protected” was once thought… it’s a waste of time. (a) people have access tot he source. (b) people want to see the implementation details as part of “full stack awareness” (c) people need to profile and build everything from scratch (re PCI).

JITs are making their way into most languages and they are really fast. I like the performance of tcl, Lua, Python, perl and Ruby… (I think I’ve decided that I like Rails but I do not like the Rails movement; different things). The fact of the matter is that everything scales in all directions. Just make it easy on yourself and reduce the amount of code.

 
Leave a comment

Posted by on 2012/02/15 in architecture, ProgLang

 

Tags: , ,

Concurrency on the JVM

I just purchase a couple of books from PragProg; Programming Clojure, Programming Scala, and Programming Concurrency on the JVM. (I’m starting to think that I already purchased the Scala book some time ago and that now I have  a dupe.)

As I’m about to embark on Clojure and Scala for the 2nd or third time I’m beginning with many of the questions I had when I started on Erlang and LUA. What does it mean to me? What is the current mindshare out there? Are there any real projects? Is there enough full-time and contract work out there to warrant even the cost of the books and the time lost reading them?

And that’s when I get really frustrated because Scala has a section on “intermixing with java” and then my head starts to spin as I remember that Lift-web (a webserver written in scala) is not really written in scala. It’s actually a combination of Scala and intermixed java (notably Jetty).

And right about there is when I lose my steam. When you are a fully vested java programmer and you know all 100B jar file filled APIs with all that it means to you… it’s hard to implement anything 100% native. So that’s the dark cloud hanging over Clojure and Scala. How can they implement all the functional goodness without getting twisted up by all that legacy poison? And so I read on.

[UPDATE: Scala and Clojure seem to intermix with Java a lot. I find this painful because I be not believe that there is a way to determine where the warts are automatically. It sure would be nice if there were some sort of dependency checker so that the graph provided some illumination before projects were implemented. Or at least some developers might contribute where the holes are. I'm about to put these books on the stack again.]

 
Leave a comment

Posted by on 2011/07/05 in ProgLang, Tools

 

Tags: , , , , , , , , ,

The Really Big O

Get your mind(s) out of the gutter. I’m actually thinking about benchmarks not bed-marks.

Back in the olden days we used to refer to a program or algorithm’s performance profile in terms of o-notiation. I’m pretty sure that most computer scientists still follow this montra and for the most part it’s probably still true.

So if it is the case that o-notation is still a real form of measure then why do most languages have different performance profiles while they perform the same work. For example 100K compares is the same when it all boils down to the assembly instruction that makes the decision:

CMP    AX, BX
JE     #SAME_VALUE

When it comes down to it every language makes decisions the same way. So why such different profiles. I say again.

First of all I think that the trouble lies in the libraries. I’m not convinced that the same care id put into every library so that the minimal number of instructions is executed. The reality is… how much code needs to execute on either side of the instruction above to actually do the work in the target language?

Secondly not all JITs are equal. And while that’s good for som languages you’d think that at some point they’d all use the same JIT. But then I’d be complaining about benevolent dictators like Oracle. I really do not like the JDK being used for Scala, Clojure and others. While they are bolted on nicely… They simply inherit everything from the JDK and whatever Java libraries you care to use. As evidenced by Lift. Which seems to depend heavily on Jetty. And if the purpose of the language is to get the benefits of a functional language… using Java libs directly would seem to defeat the purpose.

Finally whatever you are trying to accomplish in a single transaction is not unlike the CMP above. The number of comparisons over the transaction is no different between the many language. So whichever language you select it should have more to do with the overal impedance with the problem scope instead of the lonely intellectual islands.

 
Leave a comment

Posted by on 2011/06/21 in ProgLang

 

Tags: , , ,

 
One Page Docs

Creating a library one page at a time.

One Page Bugs

Reducing the friction of writing and fixing bugs or features.

Follow

Get every new post delivered to your Inbox.

Join 223 other followers