as the title suggest, i am wondering why the jena-iri module is completely absent of the javadoc in jena 4. Is the package about to be deprecated ? how does it related to the package org.apache.jena.irix ?
I mean in code we still have access to jena-iri.
Can someone be kind as to clarify the difference and purpose of both jena-iri and org.apache.jena.irix ?
There are details in the pre-release news for Jena 4.0.0, the community announcement and the IRIx javadoc.
The package is not going to be deprecated or removed.
IRIx is a wrapper abstraction to allow for multiple IRI implementations.
jena-iri is the active implementation in Jena 4.0.0.
This change allows for an additional IRI parser that is centred on the task of checking incoming data with lower overhead.
Related
EDIT: Steve Vinoski kindly provided in the comments the official name for those : tuple modules.
My original question remains though: are tuple modules officially documented by the OTP team? And are they expected to remain supported in the future?
Original question:
Consider the following erlang module:
-module(foo).
-compile(export_all).
new(Bar) -> {foo, Bar}.
get({foo, Bar}) -> Bar.
I was quite amazed to see it allows the following (using erlang 19.1):
2> Foo = foo:new(bar).
{foo,bar}
3> Foo:get().
bar
which differs quite strongly from the usual way of calling a module's function.
As far as I can tell, it seems to be a remnant of parametrized modules, which have been deprecated since R16; and I can't find anything in the official documentation stating this is a supported, stable feature of the language.
My question is: is this a documented feature of the language? And if yes, where?
As far as I know this is an undocumented remnant of parameterized modules and exists to prevent legacy code from breaking. I imagine it is intended chiefly to prevent Mochiweb from breaking, as I can't think of any other serious libraries that make use of parameterized modules.
I can't locate any documentation on it and it doesn't seem to be a subject of current consideration. There was an announcement I cannot locate (but found references to, but not links) that claimed this would be documented, but that was quite a while ago.
The release readme for R16B where parameterized modules were removed mentions this:
OTP-10616
The experimental feature "parameterized modules" (also
called "abstract modules") has been removed. For applications that
depends on parameterized modules, there is a parse transform
that can be used to still use parameterized modules.
The parse transform can be found at: github.com/erlang/pmod_transform
That issue number does not appear in OTP's issue tracker anymore, and I can't even find an occurrence of "parameterized module" or "tuple module" anywhere in OTP's Jira instance. So I'm assuming this is an undocumented legacy crutch and nothing more.
I've done a bit of searching around for a good RDF editor. But I'm not sure what one is the most utilised. Can anyone recommend one? I'm looking to write some simple RDF and maybe parse one or two RDF documents.
Many thanks
Are you looking to work at the raw Triples level and in a human readable/editable syntax such as Turtle? If so you can get by just with Notepad or maybe try out my rdfEditor which is an early Alpha release but gives you nice syntax highlighting, checking and auto-completion. This is designed only for editing raw RDF data and does not give you any IDE tools for creating your data.
If you want to work at the class/individual (i.e. more abstract level) and have the editor care about the underlying RDF then you probably want to try either TopBraid Composer or Protege
There's a new TextMate bundle for the Turtle RDF language which offers a bunch of cool features. https://github.com/peta/turtle.tmbundle
Judging from the screenshots, Rhodonite http://rhodonite.angelite.nl/ makes a good impression.
Unfortunately it seems to be abandonded and I could not get it to run on Windows7 (x64). But maybe it runs on your system (download is Windows only)
If you're looking for a web-based RDF / Ontology editor, have a look at Web Protege, an open source web-based project by the Protege team mentioned in the accepted answer.
If you need a more advanced RDF editor, look at RDF and SPARQL plugin for JetBrains IDEs. It supports all RDF 1.1 formats as well as SPARQL 1.1. Including the RDF-star and SPARQL-star extensions.
It features syntax highlighting and validation, prefixed name completion, SPARQL 1.1 Protocol support and much more.
You don't have to buy a JetBrains IDE, since the plugin works with the free versions too.
When i compiled my application in blackberry it shows the following error.
generics are not supported in -source 1.3
(use -source 5 or higher to enable generics)
how to solve this
Java 1.3 is barbaric and no one should ever have to suffer its indignities. Fortunately, there is a solution!
Generics, enums, changing return signature in overrides, and pretty much everything that makes java usable was introduced in java 1.5. (see http://en.wikipedia.org/wiki/Java_version_history). Fortunately, most of java 1.5 was designed to be backwards compatible and not require JVM / bytecode changes. (or maybe this was unfortunate, as it lead Java's implementation of generics to be much weaker than C#. just try creating a generic class with static methods / fields that use the generic parameter)
This IBM article does a good job of explaining the background:
http://www.ibm.com/developerworks/java/library/j-jtp02277.html
But this JVM similarity allowed for creation of tools such as:
http://retrotranslator.sourceforge.net/
This is the section from my Ant buildfile that calls retrotranslator:
< java jar="${transformer.jar.exe}"
fork="true"
classpath="${epic-framework.dir}/tools/retrotranslator-runtime13-1.2.9.jar:${epic-framework.dir}/tools/retrotranslator-runtime-1.2.9.jar"
args="-srcjar ${build.dir}/classes5.jar -target 1.3 -destjar ${build.dir}/classes5to3.jar"
/>
Run the converted jar through preverify.exe and then give it to rapc.exe and you will have a working Blackberry app written with Java 1.5.
Edit: I missed a key detail in my original post. In addition to being Java 1.3, the Blackberry class hierarchy is missing many classes that would normally be a part of a Java SE 1.3 JDK. The one you will hit first is StringBuilder -- javac transforms ("string" + "otherstr" + "blah blah") into StringBuilder.append("string").append("otherstr").append("blah blah"). That class doesn't exist on BB, so you break. However, BB has StringBuffer, so writing an adapter between the two is pretty easy. The one catch is that BB disallows apps from adding classes into java.*. This can be very effectively fixed in the build process: 1) build your app against Java 1.5 w/ java.lang.StringBuilder on the classpath, 2) string transform java.lang.Stringbuilder (and everything else in your compat shim) to live in com.mycorp.java.lang.StringBuilder and build it into a JAR file. 3) Use that JAR file w/ retrotranslator and retrotranslator will update all bytecode references to java.lang.StringBuilder so that they now point to com.mycorp.java.lang.StringBuilder. Now you have a java 1.3 compatible bytecode that can be run on a Blackberry.
If anyone is interested in this stuff, contact me. I could look into open sourcing the compat library I have.
This is a limitation of J2ME, which uses a subset of the J2SE (no collections, reflection, etc.) and a Java language level of 1.3. Any code written for J2SE will most likely need to be manually ported.
It seems the JDK5 is not yet supported.
Same question was asked on the blackberrry forum but about enum support:
Sadly, the BlackBerry api is very behind in terms of Java versioning. There's no Generics, no Maps, no Enums - it's based around JDK 1.3.
I believe there is no way of enabling this feature within your BlackBerry app. If you find one, I'd be very interested to hear about it.
Is this statement true:
com.sun.xml.internal package is an internal package as the name suggestes.
Users should not write code that depends on internal JDK implementation classes. Such classes are internal implementation details of the JDK and subject to change without notice
One of my colleagues used one of the classes in his code, which caused javac task in Ant fail to compile our project as the compiler couldn't find the class. Answer from Sun/Oracle says that this is expected behavior of the compiler as user shouldn't use the package.
Question is why the classes in the package made public in the first place?
Thanks,
Sarah
Sun classes in the JDK are prefixed sun.* and are not part of the public supported interface so should be used with care. From the Sun FAQ:
The classes that Sun includes with the
Java 2 SDK, Standard Edition, fall
into package groups java., javax.,
org.* and sun.. All but the sun.
packages are a standard part of the
Java platform and will be supported
into the future. In general, packages
such as sun., that are outside of the
Java platform, can be different across
OS platforms (Solaris, Windows, Linux,
Macintosh, etc.) and can change at any
time without notice with SDK versions
(1.2, 1.2.1, 1.2.3, etc). Programs
that contain direct calls to the sun.
packages are not 100% Pure Java. In
other words:
The java., javax. and org.* packages
documented in the Java 2 Platform
Standard Edition API Specification
make up the official, supported,
public interface.
If a Java program directly calls only
API in these packages, it will operate
on all Java-compatible platforms,
regardless of the underlying OS
platform.
The sun.* packages are not part of the
supported, public interface.
A Java program that directly calls
into sun.* packages is not guaranteed
to work on all Java-compatible
platforms. In fact, such a program is
not guaranteed to work even in future
versions on the same platform.
It's because Java visibility modifiers (especially at the type level, where there are only two options) don't currently have the granularity to achieve the sort of visibility you're hinting at. I don't know the specifics of the internal class or classes you're using, but basically making the classes private would have made them unfit for their intended purpose, so the only other choice was public.
Sadly JAXB (bundled with Java6) seems to rely on a non-public class "com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper" to allow you to specify namespace prefixes when marshalling to xml.
You have to really go out of your way to get this compiling with ant:
http://pragmaticintegration.blogspot.com/
Summary:
Option 1.
Add jre libs as bootclasspathref
Add property: includeJavaRuntime="yes"
Option 2.
Use JAXB-RI libs - change property to "com.sun.xml.bind.marshaller.NamespacePrefixMapper"
Also mentioned here:
Define Spring JAXB namespaces without using NamespacePrefixMapper
I am starting to learn F#. I am well versed programming languages like C# (and using the .NET framework in general), but functional programming is new to me. The way I learn best is by taking a book about the subject and starting to read - so I grabbed a copy of "Expert F#" and "F# for scientists". A few times I got the impression that those books seems already to be outdated due to recent changes in the language - nothing too dramatic, but it gives a bit of a nagging feeling that there may be more.
Now that F# 2.0 seems to have stabilized, it would be nice to see how the 'real' F# has turned out compared to the versions of the language described in those (and similar) books.
So my questions are:
what topics have changed since the books were printed, and are no longer valid as described? Are ther any chapters I can skip completely? (I am aware that some functionality has been moved to the the PowerPack, though it is not totally clear to me which functionality is in the PowerPack, and which is in the standard install)
what features of the language are described correctly, but have newer alternatives available? (Is the description of events still up to date?)
which features of the language I should be aware of that were added (or modified) since those books were written?
are there other recent changes in the language that I should be aware of?
edit:
Thanks all for the answers!
As far as release notes go, I was able to dig up the following "detailed release notes" posts on Don Syme's blog, applying to versions of F# after 1.9.2 (the version "Expert F#" mentions as being the version used in the book):
Versions 1.9.3.7 and 1.9.3.14
Version 1.9.4 and 1.9.4.19
Version 1.9.6 (September 2008 CTP)
May 2009 CTP ("Beta 1")
October 2009 ("Beta 2")
2.0 RC (February 2010)
I didn't find anything about version 1.9.5 - did that one ever exist?
I probably can't give a complete answer, but here are some things that come to mind as having undergone non-trivial changes in the past two years I've been working on F#...
Minor changes:
Many library functions have been
renamed. There originally was a penchant for underscores that has
since been removed to be more
.Net-like. So e.g. Seq.to_array is
now Seq.toArray. Some significant changes to async and quotations APIs too.
#light is now the default, you can quit putting it at the top of every file
some changes to the APIs/declarations of events and enums (the language reference and library docs on MSDN are good for up-to-date information)
no more need for [<OverloadID>] to make overloaded member functions
New features:
Units of measure was new in Beta1.
comparison and equality constraints were new in Beta2.
unmanaged constraint in RC.
(check out the "release notes" for various releases, linked in prior bullets, for more)
I'm doing a windiff of the lastest(1.9.9.9) and previous(1.9.7.8) release of FSharp.
I noticed many added calls to checkNonNull in Array, Seq, Reflect and the Quotation module. I assume these calls were added to protect F# libs from being passed nulls from another language such as C#. Any insight Brian? The function nullArg throws an ArgumentNullException.
let inline checkNonNull argName arg =
match box arg with
| null -> nullArg argName
| _ -> ()
There is a new override ToString in set and improved formatting for set and map printing with sformat aka printf "%A".
Some internal cleanup of BigInteger for use with .net 4.0.
I see a lot of internal changes to async as Brian mentioned.
Some internal changes to Event to use IObserver.
I finished going through all the changed fs files and most of the changes are to private functions that are not exposed directly. The only thing that may effect the user is different pretty printing of sets and maps.
Check out the Release Notes.